Topic: [c++std-core-27261] [std-discussion] Re:
Author: Tony Van Eerd <tvaneerd@blackberry.com>
Date: Sat, 7 Mar 2015 22:18:20 +0000
Raw View
--_000_201503072218186508625753481473blackberrycom_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
For the in-scope case, did you consider :U which is similar to ::U (which w=
ould be U in the global scope)?
Sent from my BlackBerry 10 Turing machine.
From: David Rodr=C3=ADguez Ibeas
Sent: Saturday, March 7, 2015 4:21 PM
To: std-discussion@isocpp.org
Reply To: c++std-core@accu.org
Cc: c++std-core; std-proposals@isocpp.org; faisalv@gmail.com; hsutter@micro=
soft.com
Subject: [c++std-core-27261] Re: [std-discussion] Re: Re: An implementation=
of enhanced auto deduction and abbreviated template syntax using Clang
When I went over the concepts paper there were a couple of things that trou=
bled me a bit (not a lot) and that are relevant to this discussion. The fi=
rst one is that the syntax does not call out that the identifier names a co=
ncept. This is also the case in C++14, C++11 and C++03, so nothing new, ju=
st adding one more dimension (before, a new type could be added that change=
d the meaning of an identifier), but with concepts and a non-distinguishibl=
e 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 us=
e 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, concep=
t b)' introduces a single type for both a and b.
An alternative syntax that came to mind, was to use the syntax for the temp=
late introduction as a placeholder: 'void f(concept{T} x, concept{U} y)' wo=
uld introduce two types T and U, both satisfying the 'concept' after the in=
troduction 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)'. Comp=
ared with the previous syntax, there is a bit of overhead, but I don't cons=
ider that to be a *lot* of overhead. Another advantage of this syntax is t=
hat in a concise form you can allow for multiple arguments to have differen=
t types satisfying the same concept: 'bool equal(FwdIter{It1} first, It1 la=
st, 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 placeholde=
r to enable an unconstrained template in which two arguments are of the sam=
e 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} con=
st & x, U const & y) { return x =3D=3D y; }' If this is allowed, there woul=
d not be a need to have the template introduction syntax. This is really th=
e 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 la=
mbas [](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 le=
ss alternative syntaxes, and I am willing to pay a bit on terseness (this i=
s not a huge difference) for clarity, reducing the alternatives and flexibi=
lity.
David
* An open question, for which I don't have a good answer is whether the syn=
tax should be composable: bool f(concept1{concept2{T}, concept3{U}} t, U u)=
meaning:
template <typename T, typename U>
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 t=
he template introduction one) is whether all identifiers inside the {} crea=
te new template parameters or if we can find a way of referring to identifi=
ers 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 th=
at 'T' is not a type introduced by 'Comparable{U,T}'? I have considered som=
e alternatives but I am not too fond of any of them, the one that seems lig=
hter 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>, decltype(u) =3D=3D U (i.e. the sy=
ntax 'concept{x,y,z}' is equivalent to introducing the unescaped (by lack o=
f a better name) types as template arguments and the subsitution of the pla=
ceholder for the first such introduced type.
On Sat, Mar 7, 2015 at 12:20 PM, Jonathan Wakely <cxx@kayari.org<mailto: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
> {
> 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 design
> space and that we have a path of consistency going forward)
>
>
> While for template functions the type is deduced, how could you deduce th=
e
> 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 the
> 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 e=
mail to std-discussion+unsubscribe@isocpp.org<mailto:std-discussion%2Bunsub=
scribe@isocpp.org>.
To post to this group, send email to std-discussion@isocpp.org<mailto:std-d=
iscussion@isocpp.org>.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-discuss=
ion/.
--=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/.
--_000_201503072218186508625753481473blackberrycom_
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
</head>
<body>
<div style=3D"width:100%; font-size:initial; font-family:Calibri,'Slate Pro=
',sans-serif,sans-serif; color:rgb(31,73,125); text-align:initial; backgrou=
nd-color:rgb(255,255,255)">
For the in-scope case, did you consider :U which is similar to ::U (which w=
ould be U in the global scope)?</div>
<div style=3D"width:100%; font-size:initial; font-family:Calibri,'Slate Pro=
',sans-serif,sans-serif; color:rgb(31,73,125); text-align:initial; backgrou=
nd-color:rgb(255,255,255)">
<br>
</div>
<div style=3D"width:100%; font-size:initial; font-family:Calibri,'Slate Pro=
',sans-serif,sans-serif; color:rgb(31,73,125); text-align:initial; backgrou=
nd-color:rgb(255,255,255)">
<br style=3D"display:initial">
</div>
<div style=3D"font-size:initial; font-family:Calibri,'Slate Pro',sans-serif=
,sans-serif; color:rgb(31,73,125); text-align:initial; background-color:rgb=
(255,255,255)">
Sent from my BlackBerry 10 Turing machine.</d=
iv>
<table width=3D"100%" style=3D"background-color:white; border-spacing:0px">
<tbody>
<tr>
<td colspan=3D"2" style=3D"font-size:initial; text-align:initial; backgroun=
d-color:rgb(255,255,255)">
<div style=3D"border-style:solid none none; border-top-color:rgb(181,196,22=
3); border-top-width:1pt; padding:3pt 0in 0in; font-family:Tahoma,'BB Alpha=
Sans','Slate Pro'; font-size:10pt">
<div><b>From: </b>David Rodr=C3=ADguez Ibeas</div>
<div><b>Sent: </b>Saturday, March 7, 2015 4:21 PM</div>
<div><b>To: </b>std-discussion@isocpp.org</div>
<div><b>Reply To: </b>c++std-core@accu.org</div>
<div><b>Cc: </b>c++std-core; std-proposals@isocpp.org; faisalv@gmai=
l.com; hsutter@microsoft.com</div>
<div><b>Subject: </b>[c++std-core-27261] Re: [std-discussion] Re: R=
e: An implementation of enhanced auto deduction and abbreviated template sy=
ntax using Clang</div>
</div>
</td>
</tr>
</tbody>
</table>
<div style=3D"border-style:solid none none; border-top-color:rgb(186,188,20=
9); border-top-width:1pt; font-size:initial; text-align:initial; background=
-color:rgb(255,255,255)">
</div>
<br>
<div>
<div dir=3D"ltr">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. 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 ch=
anged the meaning of an identifier), but with concepts and a non-distinguis=
hible syntax now we have more interactions.
<div><br>
</div>
<div>The second thing that concerned me is the variety of syntaxes to repre=
sent constrained templates. This is driven by two conflicting goals: =
terseness and expressive power. In addition to that, I disliked the f=
act that the use of a place-holder type has
different semantics: 'void f(auto x, auto y)' introduces two unrelated typ=
es for a and b, while 'void f(concept a, concept b)' introduces a single ty=
pe for both a and b.</div>
<div><br>
</div>
<div>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 t=
he 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 Co=
ncepts 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 advanta=
ge of this syntax is that in a concise form you can allow for multiple argu=
ments to have different types satisfying the same concept: 'bool equal(FwdI=
ter{It1} first, It1 last, FwdIter{It2}
first2, It2 last2)'. This is currently not allowed in the concepts T=
S with the more concise syntax.</div>
<div><br>
</div>
<div>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 'co=
ncept'. 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).</div>
<div><br>
</div>
<div>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 allowe=
d, there would not be a need to have the template
introduction syntax. This is really the same thing, except that it would n=
ot appear outside of the argument list, but inlined with the parameters, wh=
ich makes it a valid alternative for lambas [](Comparable{T,U} const & =
x, U const & y) { return x =3D=3D y; }.</div>
<div><br>
</div>
<div>Whether this is the good solution or something else is, I'd like to ha=
ve less alternative syntaxes, and I am willing to pay a bit on terseness (t=
his is not a huge difference) for clarity, reducing the alternatives and fl=
exibility.</div>
<div><br>
</div>
<div> David</div>
<div><br>
</div>
<div>* An open question, for which I don't have a good answer is whether th=
e syntax should be composable: bool f(concept1{concept2{T}, concept3{U}} t,=
U u) meaning:</div>
<div><br>
</div>
<div>template <typename T, typename U> </div>
<div>requires concept2<T> and concept3<U> and concept1<T,U&g=
t; // pseudo code, not sure if this is valid syntax</div>
<div>bool f(T t, U u);</div>
<div><br>
</div>
<div>* 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 ide=
ntifiers in the scope of the declaration:</div>
<div><br>
</div>
<div>void f(auto{T} t) {</div>
<div> [=3Dt](Comparable{U,T} x) { return u =3D=3D t; } // 1</di=
v>
<div>}</div>
<div><br>
</div>
<div>Is there a possible concise syntax that unambiguously allows us to sta=
te that 'T' is not a type introduced by 'Comparable{U,T}'? I have considere=
d some alternatives but I am not too fond of any of them, the one that seem=
s lighter would be abusing additional
curlies:</div>
<div><br>
</div>
<div>Comparable{T, {U}} t // This introduces a new type T, but looks up U i=
n the current scope, requires Comparable<T,U>, decltype(t) =3D=3D T</=
div>
<div>Comparable{{T}, U} u // This introduces a new type U, but looks up T i=
n the current scope, requires Comparable<T,U>, decltype(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
arguments and the subsitution of the placeholder for the first such introd=
uced type.</div>
</div>
<div class=3D"gmail_extra"><br>
<div class=3D"gmail_quote">On Sat, Mar 7, 2015 at 12:20 PM, Jonathan Wakely=
<span dir=3D"ltr">
<<a href=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex; border-left:1=
px #ccc solid; padding-left:1ex">
This wild speculation seems off-topic on c++std-core, can it be<br>
continued just at std-discussion and/or std-proposals?<br>
<div>
<div class=3D"h5"><br>
On 7 March 2015 at 16:51, Vicente J. Botet Escriba wrote:<br>
> Le 06/03/15 19:58, Tony Van Eerd a =C3=A9crit :<br>
><br>
> If all we need is auto, then is the next step:<br>
><br>
> struct X<br>
> {<br>
> int x;<br>
> auto y;<br>
> };<br>
><br>
> X is obviously a template?<br>
> So is Y:<br>
><br>
> struct Y<br>
> {<br>
> int x;<br>
> ForwardIterator y;<br>
> };<br>
><br>
> =E2=80=8E?<br>
><br>
> (Again, I'm not actually against 'auto means template function'=E2=80=
=8E; I just<br>
> bring up counter arguments to be comfortable that we explored the desi=
gn<br>
> space and that we have a path of consistency going forward)<br>
><br>
><br>
> While for template functions the type is deduced, how could you deduce=
the<br>
> type for auto or ForwardIterator. How would you declare an instance of=
X, or<br>
> a parameter of type X.<br>
><br>
> X<???> v;<br>
><br>
> what if we had<br>
><br>
> struct X<br>
> {<br>
> auto x;<br>
> auto y;<br>
> };<br>
><br>
> X<???, ???> v;<br>
><br>
> Should the parameters need to be given in the order of declaration of =
the<br>
> auto/Concept data members?<br>
><br>
> I find this confusing.<br>
><br>
> Vicente<br>
<br>
--<br>
<br>
---<br>
</div>
</div>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Discussion" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to
<a href=3D"mailto:std-discussion%2Bunsubscribe@isocpp.org">std-discussion&#=
43;unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-discussion@isocp=
p.org">std-discussion@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-discussion/" target=3D"_blank">
http://groups.google.com/a/isocpp.org/group/std-discussion/</a>.<br>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--_000_201503072218186508625753481473blackberrycom_--
.