220 16847 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.general,gmane.comp.lang.c++.isocpp.proposals Subject: Re: [c++std-core-27259] Re: Re: Re: An implementation of enhanced auto deduction and abbreviated template syntax using Clang Date: Sat, 7 Mar 2015 16:17:54 -0500 Lines: 337 Approved: news@gmane.org Message-ID: References: <465969eb-2f8b-41bb-91af-d8a9e22985e7@isocpp.org> <54F9ED4C.2030108@stroustrup.com> <20150306185818.6508625.910.1394@blackberry.com> <54FB2C7B.3080009@wanadoo.fr> Reply-To: std-discussion@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1140e85e9d39520510b95540 X-Trace: ger.gmane.org 1425763080 4568 80.91.229.3 (7 Mar 2015 21:18:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 7 Mar 2015 21:18:00 +0000 (UTC) Cc: "c++std-core" , "std-proposals@isocpp.org" , "faisalv@gmail.com" , "hsutter@microsoft.com" To: std-discussion@isocpp.org Original-X-From: std-discussion+bncBDIIVO6GQULBBA6W5WTQKGQE75KZCAQ@isocpp.org Sat Mar 07 22:17:58 2015 Return-path: Envelope-to: gclcig-std-discussion@m.gmane.org Original-Received: from mail-qg0-f69.google.com ([209.85.192.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YUM6f-0008Hf-FJ for gclcig-std-discussion@m.gmane.org; Sat, 07 Mar 2015 22:17:57 +0100 Original-Received: by qgfl89 with SMTP id l89sf67446904qgf.0 for ; Sat, 07 Mar 2015 13:17:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=wbaUeG5YWut5HFx8sZjcq6tUl4iZt5oSJM3Pm7Vspf0=; b=OPjQuaCGWJm2Df4M5rU7L5bfmwDQJUQMou/APkb7oGOXUH56mDHIGwkLk80niq1Yjf Gh7DM6COkdZr5F70aiUNsJWU468qwLoJzoSgHxofBcJq6xt1p7B0xyph9WYz1n8o51CS KccKsoPTbEOANzh7KT7RsDaA9SP2bAyyBMTB14CM/DRMX1IaEUCCRh+NGWSeB2eYH1ie qu37ISEDbsacqJbAl5nbUcPhsTqURq5C4I3qXUTkGQjSif5LsdUBDih8VcB8cRPdC1LH CIfiS5FxgbrJ80S6J1E9NW/1ze0FZXnp5Op+fzV1eks3/7lKm7rfbZzgCP0m9xMm0SGK JoKA== X-Gm-Message-State: ALoCoQkv205cvq6ZlgNLaVNR24y97hSS+686SyD3W0unIA8brPN1sqnPiC2Ur2QzactH7m6rsVWn X-Received: by 10.236.24.228 with SMTP id x64mr20029967yhx.26.1425763076024; Sat, 07 Mar 2015 13:17:56 -0800 (PST) X-BeenThere: std-discussion@isocpp.org Original-Received: by 10.182.221.169 with SMTP id qf9ls331365obc.55.gmail; Sat, 07 Mar 2015 13:17:55 -0800 (PST) X-Received: by 10.182.66.1 with SMTP id b1mr5919048obt.14.1425763075062; Sat, 07 Mar 2015 13:17:55 -0800 (PST) Original-Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com. [2607:f8b0:4003:c01::22d]) by mx.google.com with ESMTPS id d138si8548186oig.136.2015.03.07.13.17.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Mar 2015 13:17:55 -0800 (PST) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:4003:c01::22d as permitted sender) client-ip=2607:f8b0:4003:c01::22d; Original-Received: by obcva2 with SMTP id va2so8484539obc.3; Sat, 07 Mar 2015 13:17:55 -0800 (PST) X-Received: by 10.202.102.21 with SMTP id a21mr15314124oic.118.1425763074905; Sat, 07 Mar 2015 13:17:54 -0800 (PST) Original-Sender: dribeas@gmail.com Original-Received: by 10.202.169.8 with HTTP; Sat, 7 Mar 2015 13:17:54 -0800 (PST) In-Reply-To: X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:4003:c01::22d as permitted sender) smtp.mail=dribeas@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-discussion@isocpp.org; contact std-discussion+owners@isocpp.org List-ID: X-Google-Group-Id: 495566654649 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.general:5056 gmane.comp.lang.c++.isocpp.proposals:16847 Archived-At: --001a1140e85e9d39520510b95540 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable When I went over the concepts paper there were a couple of things that troubled me a bit (not a lot) and that are relevant to this discussion. The first one is that the syntax does not call out that the identifier names a concept. This is also the case in C++14, C++11 and C++03, so nothing new, just adding one more dimension (before, a new type could be added that changed the meaning of an identifier), but with concepts and a non-distinguishible syntax now we have more interactions. The second thing that concerned me is the variety of syntaxes to represent constrained templates. This is driven by two conflicting goals: terseness and expressive power. In addition to that, I disliked the fact that the use of a place-holder type has different semantics: 'void f(auto x, auto y)' introduces two unrelated types for a and b, while 'void f(concept a, concept b)' introduces a single type for both a and b. An alternative syntax that came to mind, was to use the syntax for the template introduction as a placeholder: 'void f(concept{T} x, concept{U} y)' would introduce two types T and U, both satisfying the 'concept' after the introduction of the type with 'concept{T}', the identifier T could be reused to represent the same type for different parameters: 'void f(concept{T} x, T y)' [equivalent to the Concepts TS: 'void f(concept x, concept y)'. Compared with the previous syntax, there is a bit of overhead, but I don't consider that to be a *lot* of overhead. Another advantage of this syntax is that in a concise form you can allow for multiple arguments to have different types satisfying the same concept: 'bool equal(FwdIter{It1} first, It1 last, FwdIter{It2} first2, It2 last2)'. This is currently not allowed in the concepts TS with the more concise syntax. As far as I know, this syntax is illegal in the language at this point, so it is clearly identifiable as relating to a concept, and could even be used to drive lookup to ignore types when searching for the identifier 'concept'. The same syntax could be allowed (not required) for the auto placeholder to enable an unconstrained template in which two arguments are of the same type: void f(auto{T} x, T y). Similar to the template introduction case, it would be possible to use the syntax to introduce multiple types at once: 'bool equal(Comparable{T,U} const & x, U const & y) { return x =3D=3D y; }' If this is allowed, there w= ould not be a need to have the template introduction syntax. This is really the same thing, except that it would not appear outside of the argument list, but inlined with the parameters, which makes it a valid alternative for lambas [](Comparable{T,U} const & x, U const & y) { return x =3D=3D y; }. Whether this is the good solution or something else is, I'd like to have less alternative syntaxes, and I am willing to pay a bit on terseness (this is not a huge difference) for clarity, reducing the alternatives and flexibility. David * An open question, for which I don't have a good answer is whether the syntax should be composable: bool f(concept1{concept2{T}, concept3{U}} t, U u) meaning: template requires concept2 and concept3 and concept1 // pseudo code, not sure if this is valid syntax bool f(T t, U u); * One thing that bothers me of this syntax (but that is also a problem in the template introduction one) is whether all identifiers inside the {} create new template parameters or if we can find a way of referring to identifiers in the scope of the declaration: void f(auto{T} t) { [=3Dt](Comparable{U,T} x) { return u =3D=3D t; } // 1 } Is there a possible concise syntax that unambiguously allows us to state that 'T' is not a type introduced by 'Comparable{U,T}'? I have considered some alternatives but I am not too fond of any of them, the one that seems lighter would be abusing additional curlies: Comparable{T, {U}} t // This introduces a new type T, but looks up U in the current scope, requires Comparable, decltype(t) =3D=3D T Comparable{{T}, U} u // This introduces a new type U, but looks up T in the current scope, requires Comparable, decltype(u) =3D=3D U (i.e. the syn= tax 'concept{x,y,z}' is equivalent to introducing the unescaped (by lack of a better name) types as template arguments and the subsitution of the placeholder for the first such introduced type. On Sat, Mar 7, 2015 at 12:20 PM, Jonathan Wakely wrote: > This wild speculation seems off-topic on c++std-core, can it be > continued just at std-discussion and/or std-proposals? > > On 7 March 2015 at 16:51, Vicente J. Botet Escriba wrote: > > Le 06/03/15 19:58, Tony Van Eerd a =C3=A9crit : > > > > If all we need is auto, then is the next step: > > > > struct X > > { > > int x; > > auto y; > > }; > > > > X is obviously a template? > > So is Y: > > > > struct Y > > { > > int x; > > ForwardIterator y; > > }; > > > > =E2=80=8E? > > > > (Again, I'm not actually against 'auto means template function'=E2=80= =8E; I just > > bring up counter arguments to be comfortable that we explored the desig= n > > space and that we have a path of consistency going forward) > > > > > > While for template functions the type is deduced, how could you deduce > the > > type for auto or ForwardIterator. How would you declare an instance of > X, or > > a parameter of type X. > > > > X v; > > > > what if we had > > > > struct X > > { > > auto x; > > auto y; > > }; > > > > X v; > > > > Should the parameters need to be given in the order of declaration of t= he > > auto/Concept data members? > > > > I find this confusing. > > > > Vicente > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Discussion" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-discussion+unsubscribe@isocpp.org. > To post to this group, send email to std-discussion@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-discussion/. > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Discussion" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-discussion+unsubscribe@isocpp.org. To post to this group, send email to std-discussion@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-discuss= ion/. --001a1140e85e9d39520510b95540 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When I went over the concepts paper there were a couple of= things that troubled me a bit (not a lot) and that are relevant to this di= scussion.=C2=A0 The first one is that the syntax does not call out that the= identifier names a concept.=C2=A0 This is also the case in C++14, C++11 an= d C++03, so nothing new, just adding one more dimension (before, a new type= could be added that changed the meaning of an identifier), but with concep= ts and a non-distinguishible syntax now we have more interactions.

=
The second thing that concerned me is the variety of syntaxes to= represent constrained templates.=C2=A0 This is driven by two conflicting g= oals: terseness and expressive power.=C2=A0 In addition to that, I disliked= the fact that the use of a place-holder type has different semantics: '= ;void f(auto x, auto y)' introduces two unrelated types for a and b, wh= ile 'void f(concept a, concept b)' introduces a single type for bot= h a and b.

An alternative syntax that came to mind= , was to use the syntax for the template introduction as a placeholder: = 9;void f(concept{T} x, concept{U} y)' would introduce two types T and U= , both satisfying the 'concept' after the introduction of the type = with 'concept{T}', the identifier T could be reused to represent th= e same type for different parameters: 'void f(concept{T} x, T y)' [= equivalent to the Concepts TS: 'void f(concept x, concept y)'.=C2= =A0 Compared with the previous syntax, there is a bit of overhead, but I do= n't consider that to be a *lot* of overhead.=C2=A0 Another advantage of= this syntax is that in a concise form you can allow for multiple arguments= to have different types satisfying the same concept: 'bool equal(FwdIt= er{It1} first, It1 last, FwdIter{It2} first2, It2 last2)'.=C2=A0 This i= s currently not allowed in the concepts TS with the more concise syntax.

As far as I know, this syntax is illegal in the lang= uage at this point, so it is clearly identifiable as relating to a concept,= and could even be used to drive lookup to ignore types when searching for = the identifier 'concept'.=C2=A0 The same syntax could be allowed (n= ot required) for the auto placeholder to enable an unconstrained template i= n which two arguments are of the same type: void f(auto{T} x, T y).

Similar to the template introduction case, it would be po= ssible to use the syntax to introduce multiple types at once: 'bool equ= al(Comparable{T,U} const & x, U const & y) { return x =3D=3D y; }&#= 39; If this is allowed, there would not be a need to have the template intr= oduction syntax. This is really the same thing, except that it would not ap= pear outside of the argument list, but inlined with the parameters, which m= akes it a valid alternative for lambas [](Comparable{T,U} const & x, U = const & y) { return x =3D=3D y; }.

Whether thi= s is the good solution or something else is, I'd like to have less alte= rnative syntaxes, and I am willing to pay a bit on terseness (this is not a= huge difference) for clarity, reducing the alternatives and flexibility.

=C2=A0 =C2=A0 David

* An o= pen question, for which I don't have a good answer is whether the synta= x should be composable: bool f(concept1{concept2{T}, concept3{U}} t, U u) m= eaning:

template <typename T, typename U>=C2= =A0
requires concept2<T> and concept3<U> and concept1= <T,U> // pseudo code, not sure if this is valid syntax
bool= f(T t, U u);

* One thing that bothers me of this = syntax (but that is also a problem in the template introduction one) is whe= ther all identifiers inside the {} create new template parameters or if we = can find a way of referring to identifiers in the scope of the declaration:=

void f(auto{T} t) {
=C2=A0 =C2=A0[=3Dt]= (Comparable{U,T} x) { return u =3D=3D t; } // 1
}

<= /div>
Is there a possible concise syntax that unambiguously allows us t= o state that 'T' is not a type introduced by 'Comparable{U,T}&#= 39;? I have considered some alternatives but I am not too fond of any of th= em, the one that seems lighter would be abusing additional curlies:

Comparable{T, {U}} t // This introduces a new type T, but= looks up U in the current scope, requires Comparable<T,U>, decltype(= t) =3D=3D T
Comparable{{T}, U} u // This introduces a new type U,= but looks up T in the current scope, requires Comparable<T,U>, declt= ype(u) =3D=3D U (i.e. the syntax 'concept{x,y,z}' is equivalent to = introducing the unescaped (by lack of a better name) types as template argu= ments and the subsitution of the placeholder for the first such introduced = type.

= On Sat, Mar 7, 2015 at 12:20 PM, Jonathan Wakely <cxx@kayari.org> wrote:
This wild speculation seems off= -topic on c++std-core, can it be
continued just at std-discussion and/or std-proposals?

On 7 March 2015 at 16:51, Vicente J. Botet Escriba wrote:
> Le 06/03/15 19:58, Tony Van Eerd a =C3=A9crit :
>
> If all we need is auto, then is the next step:
>
> struct X
> {
>=C2=A0 =C2=A0 =C2=A0int x;
>=C2=A0 =C2=A0 =C2=A0auto y;
> };
>
> X is obviously a template?
> So is Y:
>
> struct Y
> {
>=C2=A0 =C2=A0 =C2=A0int x;
>=C2=A0 =C2=A0 =C2=A0ForwardIterator y;
> };
>
> =E2=80=8E?
>
> (Again, I'm not actually against 'auto means template function= '=E2=80=8E; I just
> bring up counter arguments to be comfortable that we explored the desi= gn
> space and that we have a path of consistency going forward)
>
>
> While for template functions the type is deduced, how could you deduce= the
> type for auto or ForwardIterator. How would you declare an instance of= X, or
> a parameter of type X.
>
> X<???> v;
>
> what if we had
>
> struct X
> {
>=C2=A0 =C2=A0 =C2=A0auto x;
>=C2=A0 =C2=A0 =C2=A0auto y;
> };
>
> X<???, ???> v;
>
> Should the parameters need to be given in the order of declaration of = the
> auto/Concept data members?
>
> I find this confusing.
>
> Vicente

--

---
You received this message because you are subscribed to the Goo= gle Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-disc= ussion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gr= oup/std-discussion/.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-discus= sion+unsubscribe@isocpp.org.
To post to this group, send email to std-discussion@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discussion= /.
--001a1140e85e9d39520510b95540-- .