220 22242 <4c6e5856-d2e2-4080-bd03-d44aab07088f@isocpp.org> article
Path: news.gmane.org!not-for-mail
From: Nicol Bolas <jmckesson@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Return type deduction should be SFINAE friendly
Date: Wed, 4 Nov 2015 07:53:46 -0800 (PST)
Lines: 131
Approved: news@gmane.org
Message-ID: <4c6e5856-d2e2-4080-bd03-d44aab07088f@isocpp.org>
References: <a13ee5d1-9cd1-4488-9c0c-d3df3fd1f248@isocpp.org>
 <c09102a9-c3ac-46dc-9ef6-1578f0a325b3@isocpp.org>
 <8ec93f40-633c-4eaf-84b1-0fbcd4a4f9ca@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: plane.gmane.org
Mime-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_209_1720886613.1446652426168"
X-Trace: ger.gmane.org 1446652432 11040 80.91.229.3 (4 Nov 2015 15:53:52 GMT)
X-Complaints-To: usenet@ger.gmane.org
NNTP-Posting-Date: Wed, 4 Nov 2015 15:53:52 +0000 (UTC)
Cc: asutton@uakron.edu
To: ISO C++ Standard - Future Proposals <std-proposals@isocpp.org>
Original-X-From: std-proposals+bncBCEKFTV6ZUMBBC6U5CYQKGQE35G7PAA@isocpp.org Wed Nov 04 16:53:52 2015
Return-path: <std-proposals+bncBCEKFTV6ZUMBBC6U5CYQKGQE35G7PAA@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-yk0-f198.google.com ([209.85.160.198])
	by plane.gmane.org with esmtp (Exim 4.69)
	(envelope-from <std-proposals+bncBCEKFTV6ZUMBBC6U5CYQKGQE35G7PAA@isocpp.org>)
	id 1Zu0Ng-0006Vw-Nf
	for gclcip-std-proposals@m.gmane.org; Wed, 04 Nov 2015 16:53:48 +0100
Original-Received: by ykft191 with SMTP id t191sf97931465ykf.0
        for <gclcip-std-proposals@m.gmane.org>; Wed, 04 Nov 2015 07:53:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:cc:message-id:in-reply-to:references:subject
         :mime-version:content-type:x-original-sender:reply-to:precedence
         :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help
         :list-archive:list-subscribe:list-unsubscribe;
        bh=fDodKUlOVgPE0cUK4GN7v7Yl2KTaWSAXY8ejYVOgnoc=;
        b=gK1cbA/gW7f/jU+YZ9zNItGUxneFmz6gN4HNwqdVdEv6unUH7zdi6r12KA+coJcTru
         Nn1gHADCifa6kDW5PeI5ojSZpR9cL6yvJXSvYEfhYRQexyTrqUhluKreQ7ly1zLaawKF
         LfcO0IktAi9VIBxxX0tc6tRJAX43QYSIRTCfGL59f/Ydbgr/peKnGuaYuvS3LLNFnVHJ
         dBijCBMvQ0m7p0a8F9V8kB81UvUrc3p8viF//gYS+buFO4IB2NloZ3/cq/nGs6Wn4Zrl
         rFjGe6CBbJxMoZaa7J8txy6mZlkVkFmsGoI8A0tiNsrmHqFaIcyXq6rxEBzNIVWVx8xJ
         XBsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to
         :references:subject:mime-version:content-type:x-original-sender
         :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group
         :list-post:list-help:list-archive:list-subscribe:list-unsubscribe;
        bh=fDodKUlOVgPE0cUK4GN7v7Yl2KTaWSAXY8ejYVOgnoc=;
        b=caK4x1WATluLawU2PAuh/Er4aULPMPr6S0vreZ2RAMTB6vm1VJtrSEe8WFwwXXqvKL
         UrBZ9YtNNzQCA5tuYVe6UpugUKrqUBrsyaV1zalmvMtVoKV6jKSkqFFTXgLZYb/CCQ3f
         n4UoMzQ7atIU5HBE9ZdRqxdbRgrJj/h9paKpfugbvuxDiHWuzv82feFRlCIkzbSV3dzY
         ggZuUZMSV0/xuWeM/Z6MMAPXLY8XXBbCw0b5CgyOYdh+cE2PaYBd9D9lYaMDa8OgLSGR
         aJ5XOAvIZJsArMUTHNHb7s44J3ciqHbIxX3GZlkpTTPp6bEVmmnyRYlQdkU4+/ujlK/L
         u40Q==
X-Gm-Message-State: ALoCoQlKvYL6BdaBwFjeWITtu7fCKFgzgUxM6UNzSvB23RwhIfjDyPDWFDx+VSJ4qq40nMEbT1Hy
X-Received: by 10.140.235.193 with SMTP id g184mr1788780qhc.10.1446652427909;
        Wed, 04 Nov 2015 07:53:47 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.50.142.37 with SMTP id rt5ls457867igb.24.gmail; Wed, 04 Nov
 2015 07:53:46 -0800 (PST)
X-Received: by 10.50.141.138 with SMTP id ro10mr102500igb.5.1446652426947;
        Wed, 04 Nov 2015 07:53:46 -0800 (PST)
In-Reply-To: <8ec93f40-633c-4eaf-84b1-0fbcd4a4f9ca@isocpp.org>
X-Original-Sender: jmckesson@gmail.com
Precedence: list
Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org
List-ID: <std-proposals.isocpp.org>
X-Spam-Checked-In-Group: std-proposals@isocpp.org
X-Google-Group-Id: 399137483710
List-Post: <http://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <http://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <http://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <http://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:22242
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/22242>

------=_Part_209_1720886613.1446652426168
Content-Type: multipart/alternative; 
	boundary="----=_Part_210_268168931.1446652426168"

------=_Part_210_268168931.1446652426168
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 4, 2015 at 1:12:39 AM UTC-5, Tomasz wrote:
>
> W dniu =C5=9Broda, 4 listopada 2015 02:06:58 UTC+1 u=C5=BCytkownik Nicol =
Bolas=20
> napisa=C5=82:
>
One reason we don't do that, why we explicitly limit SFINAE to=20
>> parameters/return types, is so that we don't get false positives. If it=
=20
>> gets past the signature, then any errors that happen ought to be real,=
=20
>> genuine errors that a user has to face. That is, someone did something=
=20
>> *wrong*.
>>
> And I am requesting and SFINAE for return type for function using return=
=20
> type deduction.
>

That didn't address my point. Just because a function uses return type=20
deduction doesn't mean it can't get false positives.=20

Not everyone's functions that use return type deduction are tiny.

If you give someone a type and they try to default construct it and that=20
>> fails, then either your template function did something wrong or the use=
r=20
>> passed an inappropriate type. Either way, it should hard error out. We=
=20
>> (will) have concepts to check things like that in the future, so having =
a=20
>> hard error is the right thing. The declaration should not simply disappe=
ar.
>>
>
> Have you checked Motivation 3 regarding the concepts. Lack of SFINAE for=
=20
> return type deduction essentially breaks concept for generic lambda uses,=
=20
> And I do not think that users will constrain every lambda they will write=
..=20
>

I don't see the idea behind Motivation 3. It seems like an admission that=
=20
proper use of concepts will effectively solve the problem. Then you just=20
declare that people won't always use them.

My response to that is... tough. If we give people a tool that fixes a=20
problem, and they refuse to use that tool to fix that exact problem, I=20
refuse to care that they still have the problem.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_210_268168931.1446652426168
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, November 4, 2015 at 1:12:39 AM UTC-5, Tomasz wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div>W dniu =C5=9Broda, 4 listopada 2015=
 02:06:58 UTC+1 u=C5=BCytkownik Nicol Bolas napisa=C5=82:<br></div></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">One reason we d=
on&#39;t do that, why we explicitly limit SFINAE to parameters/return types=
, is so that we don&#39;t get false positives. If it gets past the signatur=
e, then any errors that happen ought to be real, genuine errors that a user=
 has to face. That is, someone did something <i>wrong</i>.<br></div></block=
quote><div>And I am requesting and SFINAE for return type for function usin=
g return type deduction.<br></div></div></blockquote><div><br>That didn&#39=
;t address my point. Just because a function uses return type deduction doe=
sn&#39;t mean it can&#39;t get false positives. <br><br>Not everyone&#39;s =
functions that use return type deduction are tiny.<br></div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">If you give someone a type and =
they try to default construct it and that fails, then either your template =
function did something wrong or the user passed an inappropriate type. Eith=
er way, it should hard error out. We (will) have concepts to check things l=
ike that in the future, so having a hard error is the right thing. The decl=
aration should not simply disappear.<br></div></blockquote><div><br>Have yo=
u checked Motivation 3 regarding the concepts. Lack of SFINAE for return ty=
pe deduction essentially breaks concept for generic lambda uses, And I do n=
ot think that users will constrain every lambda they will write. <br></div>=
</div></blockquote><div><br>I don&#39;t see the idea behind Motivation 3. I=
t seems like an admission that proper use of concepts will effectively solv=
e the problem. Then you just declare that people won&#39;t always use them.=
<br><br>My response to that is... tough. If we give people a tool that fixe=
s a problem, and they refuse to use that tool to fix that exact problem, I =
refuse to care that they still have the problem.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_210_268168931.1446652426168--
------=_Part_209_1720886613.1446652426168--

.
