220 22257 article Path: news.gmane.org!not-for-mail From: Tomasz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Return type deduction should be SFINAE friendly Date: Wed, 4 Nov 2015 14:47:35 -0800 (PST) Lines: 229 Approved: news@gmane.org Message-ID: References: <8ec93f40-633c-4eaf-84b1-0fbcd4a4f9ca@isocpp.org> <4c6e5856-d2e2-4080-bd03-d44aab07088f@isocpp.org> <2a1ceb7a-3ce4-4543-add6-e05c2f7d69eb@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_135_477587759.1446677255710" X-Trace: ger.gmane.org 1446677261 12934 80.91.229.3 (4 Nov 2015 22:47:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Nov 2015 22:47:41 +0000 (UTC) Cc: asutton@uakron.edu To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNPVXXG6IGBBCEW5KYQKGQEUBZCFKA@isocpp.org Wed Nov 04 23:47:41 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f197.google.com ([209.85.220.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zu6qA-0001XY-Sq for gclcip-std-proposals@m.gmane.org; Wed, 04 Nov 2015 23:47:39 +0100 Original-Received: by qkcl124 with SMTP id l124sf114330460qkc.1 for ; Wed, 04 Nov 2015 14:47:37 -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=WVSMCa1OpJidj6TMTG/zdkorldddG/PVcxvcB8YjfRM=; b=lcUo3Mi5KEZfHr5pQR1aWcHgcfhBGu8QGgd92KCovghYX/Mfv5m5a0NcrBr4XFLXRu eE28TuPd9vh5MMiOADDdEVTBBgN911Ph604gTkP3P/3xUFy0U0K8JX8ubzLqGtESu9sW Jc9vhTqngE0GX4tVmZYKJIFdf0ligpZeZQBUtTGeJ1Pu/UM1z8xYbwkVGfRl+6FpTDoA Wy/Z0ky2EifL6ObRlveLpawx6qzIRkMMEYWBvaubFUJIxgOOtE7wmIobAEqDhw5nKdc4 6wXm1II4uA3mqp6B9KMkUwW1EbIJugSWGGtkWGFBcZEk3bFjGIoefn3jDBf0/xrbBaVY vlcA== 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=WVSMCa1OpJidj6TMTG/zdkorldddG/PVcxvcB8YjfRM=; b=e8LwwmrxZ/TZO6xaZIjQSWqis2ewsPOmd4ACntlC9hHXQ9oatVIJ4ikJplsoR/C5A8 o9b2Bo0sR/caofHOeRBIsT+ZcPtSk7i7F0mDWvJhwhTeohhkEBNCHPOkfDpBnuPgOAy+ 4L46Pg7l2ZAeNZoOgKhCHt5p0Qzoc/dUUoVvoPMU6sas1D+y2K9bGh/eccnJvYwhMQW1 Zhhy51U8CxmDjbe8EdIBpKWJEfwLnHmZueA9kraOvEyTtrRjtmIE8z+kFT33vcQRWeEz KTYMH7uhqWflNHzYjIKGEuGqOt1X+u/y/dUn77uPSi9N6pqsrSqwAiUgmElQirwgbrTX qIbQ== X-Gm-Message-State: ALoCoQlgTiBvnue4uZnosbMHGRE/oQdp2jwfdEIhb8EP5fJkfc+tcQ+7T21toc0XgZMsHWzlgHGN X-Received: by 10.140.196.76 with SMTP id r73mr3540624qha.3.1446677257770; Wed, 04 Nov 2015 14:47:37 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.134.149 with SMTP id q21ls565302ioi.93.gmail; Wed, 04 Nov 2015 14:47:36 -0800 (PST) X-Received: by 10.50.8.68 with SMTP id p4mr184018iga.8.1446677256637; Wed, 04 Nov 2015 14:47:36 -0800 (PST) In-Reply-To: X-Original-Sender: tomaszkam@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:22257 Archived-At: ------=_Part_135_477587759.1446677255710 Content-Type: multipart/alternative; boundary="----=_Part_136_213742746.1446677255711" ------=_Part_136_213742746.1446677255711 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, November 4, 2015 at 7:39:19 PM UTC+1, Nicol Bolas wrote: > > On Wednesday, November 4, 2015 at 11:20:27 AM UTC-5, Tomasz wrote: >> >> W dniu =C5=9Broda, 4 listopada 2015 16:53:46 UTC+1 u=C5=BCytkownik Nicol= Bolas=20 >> napisa=C5=82: >>> >>> 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 Nic= ol 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 somethin= g=20 >>>>> *wrong*. >>>>> >>>> And I am requesting and SFINAE for return type for function using=20 >>>> return 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 tha= t=20 >>>>> fails, then either your template function did something wrong or the = user=20 >>>>> passed an inappropriate type. Either way, it should hard error out. W= e=20 >>>>> (will) have concepts to check things like that in the future, so havi= ng a=20 >>>>> hard error is the right thing. The declaration should not simply disa= ppear. >>>>> >>>> >>>> Have you checked Motivation 3 regarding the concepts. Lack of SFINAE= =20 >>>> for return type deduction essentially breaks concept for generic lambd= a=20 >>>> uses, And I do not think that users will constrain every lambda they w= ill=20 >>>> write.=20 >>>> >>> >>> I don't see the idea behind Motivation 3. It seems like an admission=20 >>> that proper use of concepts will effectively solve the problem. Then yo= u=20 >>> just 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. >>> >> >> Lambda was created as a tool for creating ad-hoc functor for use with ST= L=20 >> algorithm in local scope, so requiring them to be constrained, will lead= to=20 >> an explosion of ad-hoc constrains, that cannot be declared locally, i.e.= =20 >> lead to C++11 design. >> > > Here's what I don't understand about this. > > You don't want this feature to allow SFINAE overloading. You don't want= =20 > this feature to make erroneous code less erroneous (code that triggers yo= ur=20 > auto-SFINAE will fail to instantiate something, which is still an error).= =20 > The *only thing* this feature does is change what the error message you= =20 > get is. > > I am not wanting to allow SFINAE overloading on the function body, i.e.,= =20 allow following two declarations to be present and unambiguous: template auto f(T x) { return x =3D=3D 2; } template auto f(T x) { return x =3D=3D std::string("2"); } As this is requiring the whole body to be mangled into signature,=20 introduces full instatiation as part of overload resolution and other=20 problems listed in this thread. However, my proposal is allowing second level of SFINAE overloads, that=20 makes overload depended on validity of other expression. For example=20 template constuctor of std::function from type U is viable only= =20 if U can be called with int and returns an int. To check that, return type= =20 of the function needs to be determined anyway, and I am requiring that, if= =20 this leads to template instantiation, then error produced during it will=20 lead to elimination of overload, instead of hard error. This will lead to existing C++14 library features to work with generic=20 lambdas (see motivation 1). That changes does not only change error message= .. --=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_136_213742746.1446677255711 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, November 4, 2015 at 7:39:19 PM UTC+1, Nicol Bolas wrote:On Wednesday, November 4, 2015 at 1= 1:20:27 AM UTC-5, Tomasz wrote:
W dn= iu =C5=9Broda, 4 listopada 2015 16:53:46 UTC+1 u=C5=BCytkownik Nicol Bolas = napisa=C5=82:
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=BCytko= wnik Nicol Bolas napisa=C5=82:
One reason we don't do that, why we explici= tly limit SFINAE to parameters/return types, is so that we don't get fa= lse positives. If it gets past the signature, then any errors that happen o= ught to be real, genuine errors that a user has to face. That is, someone d= id something wrong.
And I am requesting a= nd SFINAE for return type for function using return type deduction.

That didn't address my point. Just becaus= e a function uses return type deduction doesn't mean it can't get f= alse positives.

Not everyone's functions that use return type d= eduction are tiny.

If you give someone a type and they try to default construct it an= d that fails, then either your template function did something wrong or the= user passed an inappropriate type. Either way, it should hard error out. W= e (will) have concepts to check things like that in the future, so having a= hard error is the right thing. The declaration should not simply disappear= ..

Have you checked Motivation 3 regarding th= e concepts. Lack of SFINAE for return type deduction essentially breaks con= cept for generic lambda uses, And I do not think that users will constrain = every lambda they will write.

I don&#= 39;t see the idea behind Motivation 3. It seems like an admission that prop= er use of concepts will effectively solve the problem. Then you just declar= e that people won't always use them.

My response to that is... t= ough. If we give people a tool that fixes a problem, and they refuse to use= that tool to fix that exact problem, I refuse to care that they still have= the problem.

Lambda was created as a tool f= or creating ad-hoc functor for use with STL algorithm in local scope, so re= quiring them to be constrained, will lead to an explosion of ad-hoc constra= ins, that cannot be declared locally, i.e. lead to C++11 design.
<= /blockquote>

Here's what I don't understand about this.
=
You don't want this feature to allow SFINAE overloading. You don= 9;t want this feature to make erroneous code less erroneous (code that trig= gers your auto-SFINAE will fail to instantiate something, which is still an= error). The only thing this feature does is change what the error m= essage you get is.

I am not wanting to allow= SFINAE overloading on the function body,=20 i.e., allow following two declarations to be present and unambiguous:
te= mplate<typename T>
auto f(T x) { return x =3D=3D 2; }

templ= ate<typename T>
auto f(T x) { return x =3D=3D std::string("2&= quot;); }
As this is requiring the whole body to be mangled into signature,=20 introduces full instatiation as part of overload resolution and other=20 problems listed in this thread.

However, my proposal is allowing=20 second level of SFINAE overloads, that makes overload depended on=20 validity of other expression. For example template constuctor of std::funct= ion<int(int)>=20 from type U is viable only if U can be called with int and returns an int. = To check that, return type of the function needs to be determined anyway,=20 and I am requiring that, if this leads to template instantiation, then erro= r=20 produced during it will lead to elimination of overload, instead of=20 hard error.

This will lead to existing C++14 library features to=20 work with generic lambdas (see motivation 1). That changes does not only change error message.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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-proposals/<= /a>.
------=_Part_136_213742746.1446677255711-- ------=_Part_135_477587759.1446677255710-- .