Topic: Contract attributes and trailing return types
Author: "'Hamza Sood' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 26 Jul 2018 13:02:03 -0700 (PDT)
Raw View
------=_Part_10211_1294147454.1532635323114
Content-Type: multipart/alternative;
boundary="----=_Part_10212_1566364973.1532635323115"
------=_Part_10212_1566364973.1532635323115
Content-Type: text/plain; charset="UTF-8"
If I'm interpreting the current draft standard correctly, it looks like
contract attributes don't work particularly well with trailing return types.
E.g. here's an example from the proposal, re-written with a trailing return
type:
*auto f(int x, int y) [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]] -> int;*
The return type ends up really far away from the rest of the function
declaration, which makes it very difficult to spot.
I think it'd be better if contract attributes applied to a trailing return
type are considered part of the function declaration, which would mean that
the above could be written as:
*auto f(int x, int y) -> int [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]];*
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-4887-a4ad-d11a50107aa9%40isocpp.org.
------=_Part_10212_1566364973.1532635323115
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If I'm interpreting the current draft standard correct=
ly, it looks like contract attributes don't work particularly well with=
trailing return types.<div><br></div><div>E.g. here's an example from =
the proposal, re-written with a trailing return type:</div><div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px=
solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><pre style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0);"><b><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">[[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
expects</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">></span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">expects</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">!=3D</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">ensures result</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> result </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">]]</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&=
gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span></b></pre></div></cod=
e></div><br>The return type ends up really far away from the rest of the fu=
nction declaration, which makes it very difficult to spot.</div><div><br></=
div><div>I think it'd be better if contract attributes applied to a tra=
iling return type are considered part of the function declaration, which wo=
uld mean that the above could be written as:</div><div><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint" style=3D"caret-color: rgb(102, 0, 102);"><pre style=
=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><b><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">[[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">exp=
ects</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">expects</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">!=3D</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">ensures result</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> result </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">y</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">]];</span></b></pre></div></code></div><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-4887-a4ad-d11a50107aa9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-4887-a4ad-d11a50107aa9=
%40isocpp.org</a>.<br />
------=_Part_10212_1566364973.1532635323115--
------=_Part_10211_1294147454.1532635323114--
.
Author: Bo Persson <bop@gmb.dk>
Date: Thu, 26 Jul 2018 23:11:42 +0200
Raw View
On 2018-07-26 22:02, 'Hamza Sood' via ISO C++ Standard - Future
Proposals wrote:
> If I'm interpreting the current draft standard correctly, it looks like
> contract attributes don't work particularly well with trailing return types.
>
> E.g. here's an example from the proposal, re-written with a trailing
> return type:
> |
>
> *auto f(intx,inty)
> [[expects:x>0]]
> [[expects:y!=0]]
> [[ensures result:result >x+y]]->int;
> *
>
> |
>
> The return type ends up really far away from the rest of the function
> declaration, which makes it very difficult to spot.
>
> I think it'd be better if contract attributes applied to a trailing
> return type are considered part of the function declaration, which would
> mean that the above could be written as:
> |
>
> *auto f(intx,inty)->int
> [[expects:x>0]]
> [[expects:y!=0]]
> [[ensures result:result >x+y]];*
>
> |
On the other hand, you can alredy have
template<class... Types> auto f(Types&&... x) const volatile &&
noexcept(std::conjunction_v<std::is_nothrow_move_constructible<Types>...>)
-> int;
So why not add some more stuff before the -> ? :-)
Or perhaps we need a general cleanup here, not just for contracts?
Bo Persson
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pjddad%24kii%241%40blaine.gmane.org.
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Thu, 26 Jul 2018 14:49:10 -0700
Raw View
--000000000000d1ace00571edf7c1
Content-Type: text/plain; charset="UTF-8"
Attributes with trailing return type generally suffer from this problem:
auto f(int x, int y) [[deprecated]] -> int;
If you don't mind, you can put the contracts before, just like we normally
do with attributes:
[[expects: x>0]]
[[expects: y!=0]]
[[ensures result: result > x+y]]
auto f(int x, int y) -> int;
On Thu, Jul 26, 2018 at 1:02 PM 'Hamza Sood' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> If I'm interpreting the current draft standard correctly, it looks like
> contract attributes don't work particularly well with trailing return types.
>
> E.g. here's an example from the proposal, re-written with a trailing
> return type:
>
>
>
>
>
> *auto f(int x, int y) [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]] -> int;*
>
>
> The return type ends up really far away from the rest of the function
> declaration, which makes it very difficult to spot.
>
> I think it'd be better if contract attributes applied to a trailing return
> type are considered part of the function declaration, which would mean that
> the above could be written as:
>
>
>
>
> *auto f(int x, int y) -> int [[expects: x>0]] [[expects: y!=0]] [[ensures result: result > x+y]];*
>
>
> --
> 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-4887-a4ad-d11a50107aa9%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-4887-a4ad-d11a50107aa9%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3o0_8STpgWt6NVQ1eejD-krUefpJkk%3DrDmkOK-co-1LQ%40mail.gmail.com.
--000000000000d1ace00571edf7c1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Attributes with trailing return type generally suffer from=
this problem:<div><br></div><div>auto f(int x, int y) [[deprecated]] ->=
int;</div><div><br></div><div>If you don't mind, you can put the contr=
acts before, just like we normally do with attributes:</div><div><br></div>=
<div><div>[[expects: x>0]]</div><div>[[expects: y!=3D0]]</div><div>[[ens=
ures result: result > x+y]]</div></div><div>auto f(int x, int y) -> i=
nt;</div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Thu, Jul 26, 2018 at 1:02 PM 'Hamza Sood' via ISO C++ Standar=
d - Future Proposals <<a href=3D"mailto:std-proposals@isocpp.org">std-pr=
oposals@isocpp.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">If I'm interpreting the current draft standard correctl=
y, it looks like contract attributes don't work particularly well with =
trailing return types.<div><br></div><div>E.g. here's an example from t=
he proposal, re-written with a trailing return type:</div><div><div class=
=3D"m_1467168363808857441prettyprint" style=3D"background-color:rgb(250,250=
,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code class=
=3D"m_1467168363808857441prettyprint"><div class=3D"m_1467168363808857441su=
bprettyprint"><pre style=3D"color:rgb(0,0,0)"><b><span style=3D"color:#008"=
class=3D"m_1467168363808857441styled-by-prettify">auto</span><span style=
=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify"> f</span>=
<span style=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettify=
">(</span><span style=3D"color:#008" class=3D"m_1467168363808857441styled-b=
y-prettify">int</span><span style=3D"color:#000" class=3D"m_146716836380885=
7441styled-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_1467=
168363808857441styled-by-prettify">,</span><span style=3D"color:#000" class=
=3D"m_1467168363808857441styled-by-prettify"> </span><span style=3D"color:#=
008" class=3D"m_1467168363808857441styled-by-prettify">int</span><span styl=
e=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify"> y</span=
><span style=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettif=
y">)</span><span style=3D"color:#000" class=3D"m_1467168363808857441styled-=
by-prettify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D"m_146716=
8363808857441styled-by-prettify">[[</span><span style=3D"color:#000" class=
=3D"m_1467168363808857441styled-by-prettify">expects</span><span style=3D"c=
olor:#660" class=3D"m_1467168363808857441styled-by-prettify">:</span><span =
style=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify"> x</=
span><span style=3D"color:#660" class=3D"m_1467168363808857441styled-by-pre=
ttify">></span><span style=3D"color:#066" class=3D"m_1467168363808857441=
styled-by-prettify">0</span><span style=3D"color:#660" class=3D"m_146716836=
3808857441styled-by-prettify">]]</span><span style=3D"color:#000" class=3D"=
m_1467168363808857441styled-by-prettify"><br>=C2=A0 </span><span style=3D"c=
olor:#660" class=3D"m_1467168363808857441styled-by-prettify">[[</span><span=
style=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify">exp=
ects</span><span style=3D"color:#660" class=3D"m_1467168363808857441styled-=
by-prettify">:</span><span style=3D"color:#000" class=3D"m_1467168363808857=
441styled-by-prettify"> y</span><span style=3D"color:#660" class=3D"m_14671=
68363808857441styled-by-prettify">!=3D</span><span style=3D"color:#066" cla=
ss=3D"m_1467168363808857441styled-by-prettify">0</span><span style=3D"color=
:#660" class=3D"m_1467168363808857441styled-by-prettify">]]</span><span sty=
le=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color:#660" class=3D"m_1467168363808857441styled-=
by-prettify">[[</span><span style=3D"color:#000" class=3D"m_146716836380885=
7441styled-by-prettify">ensures result</span><span style=3D"color:#660" cla=
ss=3D"m_1467168363808857441styled-by-prettify">:</span><span style=3D"color=
:#000" class=3D"m_1467168363808857441styled-by-prettify"> result </span><sp=
an style=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettify">&=
gt;</span><span style=3D"color:#000" class=3D"m_1467168363808857441styled-b=
y-prettify"> x</span><span style=3D"color:#660" class=3D"m_1467168363808857=
441styled-by-prettify">+</span><span style=3D"color:#000" class=3D"m_146716=
8363808857441styled-by-prettify">y</span><span style=3D"color:#660" class=
=3D"m_1467168363808857441styled-by-prettify">]]</span><span style=3D"color:=
#000" class=3D"m_1467168363808857441styled-by-prettify"> </span><span style=
=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettify">-></sp=
an><span style=3D"color:#000" class=3D"m_1467168363808857441styled-by-prett=
ify"> </span><span style=3D"color:#008" class=3D"m_1467168363808857441style=
d-by-prettify">int</span><span style=3D"color:#660" class=3D"m_146716836380=
8857441styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_14=
67168363808857441styled-by-prettify"><br></span></b></pre></div></code></di=
v><br>The return type ends up really far away from the rest of the function=
declaration, which makes it very difficult to spot.</div><div><br></div><d=
iv>I think it'd be better if contract attributes applied to a trailing =
return type are considered part of the function declaration, which would me=
an that the above could be written as:</div><div><div class=3D"m_1467168363=
808857441prettyprint" style=3D"background-color:rgb(250,250,250);border:1px=
solid rgb(187,187,187);word-wrap:break-word"><code class=3D"m_146716836380=
8857441prettyprint"><div class=3D"m_1467168363808857441subprettyprint"><pre=
style=3D"color:rgb(0,0,0)"><b><span style=3D"color:#008" class=3D"m_146716=
8363808857441styled-by-prettify">auto</span><span style=3D"color:#000" clas=
s=3D"m_1467168363808857441styled-by-prettify"> f</span><span style=3D"color=
:#660" class=3D"m_1467168363808857441styled-by-prettify">(</span><span styl=
e=3D"color:#008" class=3D"m_1467168363808857441styled-by-prettify">int</spa=
n><span style=3D"color:#000" class=3D"m_1467168363808857441styled-by-pretti=
fy"> x</span><span style=3D"color:#660" class=3D"m_1467168363808857441style=
d-by-prettify">,</span><span style=3D"color:#000" class=3D"m_14671683638088=
57441styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_1467=
168363808857441styled-by-prettify">int</span><span style=3D"color:#000" cla=
ss=3D"m_1467168363808857441styled-by-prettify"> y</span><span style=3D"colo=
r:#660" class=3D"m_1467168363808857441styled-by-prettify">)</span><span sty=
le=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify"> </span=
><span style=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettif=
y">-></span><span style=3D"color:#000" class=3D"m_1467168363808857441sty=
led-by-prettify"> </span><span style=3D"color:#008" class=3D"m_146716836380=
8857441styled-by-prettify">int</span><span style=3D"color:#000" class=3D"m_=
1467168363808857441styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or:#660" class=3D"m_1467168363808857441styled-by-prettify">[[</span><span s=
tyle=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify">expec=
ts</span><span style=3D"color:#660" class=3D"m_1467168363808857441styled-by=
-prettify">:</span><span style=3D"color:#000" class=3D"m_146716836380885744=
1styled-by-prettify"> x</span><span style=3D"color:#660" class=3D"m_1467168=
363808857441styled-by-prettify">></span><span style=3D"color:#066" class=
=3D"m_1467168363808857441styled-by-prettify">0</span><span style=3D"color:#=
660" class=3D"m_1467168363808857441styled-by-prettify">]]</span><span style=
=3D"color:#000" class=3D"m_1467168363808857441styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color:#660" class=3D"m_1467168363808857441styled-=
by-prettify">[[</span><span style=3D"color:#000" class=3D"m_146716836380885=
7441styled-by-prettify">expects</span><span style=3D"color:#660" class=3D"m=
_1467168363808857441styled-by-prettify">:</span><span style=3D"color:#000" =
class=3D"m_1467168363808857441styled-by-prettify"> y</span><span style=3D"c=
olor:#660" class=3D"m_1467168363808857441styled-by-prettify">!=3D</span><sp=
an style=3D"color:#066" class=3D"m_1467168363808857441styled-by-prettify">0=
</span><span style=3D"color:#660" class=3D"m_1467168363808857441styled-by-p=
rettify">]]</span><span style=3D"color:#000" class=3D"m_1467168363808857441=
styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D"m=
_1467168363808857441styled-by-prettify">[[</span><span style=3D"color:#000"=
class=3D"m_1467168363808857441styled-by-prettify">ensures result</span><sp=
an style=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettify">:=
</span><span style=3D"color:#000" class=3D"m_1467168363808857441styled-by-p=
rettify"> result </span><span style=3D"color:#660" class=3D"m_1467168363808=
857441styled-by-prettify">></span><span style=3D"color:#000" class=3D"m_=
1467168363808857441styled-by-prettify"> x</span><span style=3D"color:#660" =
class=3D"m_1467168363808857441styled-by-prettify">+</span><span style=3D"co=
lor:#000" class=3D"m_1467168363808857441styled-by-prettify">y</span><span s=
tyle=3D"color:#660" class=3D"m_1467168363808857441styled-by-prettify">]];</=
span></b></pre></div></code></div><br></div></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-4887-a4ad-d11a50107aa9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b39be2a8-c0c4-=
4887-a4ad-d11a50107aa9%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq3o0_8STpgWt6NVQ1eejD-krUefpJkk=
%3DrDmkOK-co-1LQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3o0_8STp=
gWt6NVQ1eejD-krUefpJkk%3DrDmkOK-co-1LQ%40mail.gmail.com</a>.<br />
--000000000000d1ace00571edf7c1--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Jul 2018 15:01:18 -0700 (PDT)
Raw View
------=_Part_416_1472954731.1532642479039
Content-Type: multipart/alternative;
boundary="----=_Part_417_135283010.1532642479039"
------=_Part_417_135283010.1532642479039
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Nicolas Lesser wrote:
>
> Attributes with trailing return type generally suffer from this problem:
>
> auto f(int x, int y) [[deprecated]] -> int;
>
> If you don't mind, you can put the contracts before, just like we normally
> do with attributes:
>
> [[expects: x>0]]
> [[expects: y!=0]]
> [[ensures result: result > x+y]]
> auto f(int x, int y) -> int;
>
Not according to P0542. Contracts "appertain to the function type", so they
can't be prefixed.
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%40isocpp.org.
------=_Part_417_135283010.1532642479039
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Ni=
colas Lesser wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">Attributes with trailing return type generally suffer from this probl=
em:<div><br></div><div>auto f(int x, int y) [[deprecated]] -> int;</div>=
<div><br></div><div>If you don't mind, you can put the contracts before=
, just like we normally do with attributes:</div><div><br></div><div><div>[=
[expects: x>0]]</div><div>[[expects: y!=3D0]]</div><div>[[ensures result=
: result > x+y]]</div></div><div>auto f(int x, int y) -> int;</div></=
div></blockquote><div><br></div><div>Not according to P0542. Contracts &quo=
t;appertain to the function type", so they can't be prefixed.</div=
><br></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380=
%40isocpp.org</a>.<br />
------=_Part_417_135283010.1532642479039--
------=_Part_416_1472954731.1532642479039--
.
Author: Nicolas Lesser <blitzrakete@gmail.com>
Date: Thu, 26 Jul 2018 15:03:39 -0700
Raw View
--000000000000a48ad10571ee2baf
Content-Type: text/plain; charset="UTF-8"
Ah, didn't know that "appertain" means that. Thanks for correcting me :)
On Thu, Jul 26, 2018 at 3:01 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Nicolas Lesser wrote:
>>
>> Attributes with trailing return type generally suffer from this problem:
>>
>> auto f(int x, int y) [[deprecated]] -> int;
>>
>> If you don't mind, you can put the contracts before, just like we
>> normally do with attributes:
>>
>> [[expects: x>0]]
>> [[expects: y!=0]]
>> [[ensures result: result > x+y]]
>> auto f(int x, int y) -> int;
>>
>
> Not according to P0542. Contracts "appertain to the function type", so
> they can't be prefixed.
>
> --
> 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gmail.com.
--000000000000a48ad10571ee2baf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ah, didn't know that "appertain" means that.=
Thanks for correcting me :)</div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Thu, Jul 26, 2018 at 3:01 PM Nicol Bolas <<a href=3D"mailto:=
jmckesson@gmail.com">jmckesson@gmail.com</a>> wrote:<br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><br><br>On Thursday, July 26, 2018 at=
5:49:24 PM UTC-4, Nicolas Lesser wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Attributes with trailing return type generally suffer=
from this problem:<div><br></div><div>auto f(int x, int y) [[deprecated]] =
-> int;</div><div><br></div><div>If you don't mind, you can put the =
contracts before, just like we normally do with attributes:</div><div><br><=
/div><div><div>[[expects: x>0]]</div><div>[[expects: y!=3D0]]</div><div>=
[[ensures result: result > x+y]]</div></div><div>auto f(int x, int y) -&=
gt; int;</div></div></blockquote><div><br></div><div>Not according to P0542=
.. Contracts "appertain to the function type", so they can't b=
e prefixed.</div><br></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-=
4dc2-a9ca-098f1ed8b380%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BH=
T75HAfeRWY_sY0EAGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__Q=
T0t3Xk_-tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gmail.com</a>.<br />
--000000000000a48ad10571ee2baf--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Thu, 26 Jul 2018 15:59:11 -0700
Raw View
--00000000000031ebd40571eef23f
Content-Type: text/plain; charset="UTF-8"
Also, the function parameters would not be in scope in an attribute
appearing in that location.
On Thu, 26 Jul 2018 at 15:03, Nicolas Lesser <blitzrakete@gmail.com> wrote:
> Ah, didn't know that "appertain" means that. Thanks for correcting me :)
>
> On Thu, Jul 26, 2018 at 3:01 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Nicolas Lesser wrote:
>>>
>>> Attributes with trailing return type generally suffer from this problem:
>>>
>>> auto f(int x, int y) [[deprecated]] -> int;
>>>
>>> If you don't mind, you can put the contracts before, just like we
>>> normally do with attributes:
>>>
>>> [[expects: x>0]]
>>> [[expects: y!=0]]
>>> [[ensures result: result > x+y]]
>>> auto f(int x, int y) -> int;
>>>
>>
>> Not according to P0542. Contracts "appertain to the function type", so
>> they can't be prefixed.
>>
>> --
>> 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
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D2%3DVuqbb6zRg3bjfr3_ZPWHO%3D1cDXz1FsON%3DeAnNzf2w%40mail.gmail.com.
--00000000000031ebd40571eef23f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Also, the function parameters would not be in scope in an =
attribute appearing in that location.<br><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr">On Thu, 26 Jul 2018 at 15:03, Nicolas Lesser <<a href=3D"m=
ailto:blitzrakete@gmail.com">blitzrakete@gmail.com</a>> wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Ah, didn't know that &q=
uot;appertain" means that. Thanks for correcting me :)</div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jul 26, 2018 at 3:01 PM Nicol=
Bolas <<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckess=
on@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><br><br>On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Nicolas L=
esser wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Attrib=
utes with trailing return type generally suffer from this problem:<div><br>=
</div><div>auto f(int x, int y) [[deprecated]] -> int;</div><div><br></d=
iv><div>If you don't mind, you can put the contracts before, just like =
we normally do with attributes:</div><div><br></div><div><div>[[expects: x&=
gt;0]]</div><div>[[expects: y!=3D0]]</div><div>[[ensures result: result >=
; x+y]]</div></div><div>auto f(int x, int y) -> int;</div></div></blockq=
uote><div><br></div><div>Not according to P0542. Contracts "appertain =
to the function type", so they can't be prefixed.</div><br></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-=
4dc2-a9ca-098f1ed8b380%40isocpp.org</a>.<br>
</blockquote></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BH=
T75HAfeRWY_sY0EAGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gma=
il.com</a>.<br>
</blockquote></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D2%3DVuqbb6zRg3bjfr3_ZPWHO%3=
D1cDXz1FsON%3DeAnNzf2w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3=
D2%3DVuqbb6zRg3bjfr3_ZPWHO%3D1cDXz1FsON%3DeAnNzf2w%40mail.gmail.com</a>.<br=
/>
--00000000000031ebd40571eef23f--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Thu, 26 Jul 2018 21:07:45 -0400
Raw View
--0000000000004b5c940571f0bd56
Content-Type: text/plain; charset="UTF-8"
How does this compare to where `requires` goes? Is that before or after
the trailing return?
Maybe contracts and requires should go next to each other? (One being
compile-time constraints, the other runtime.)
On Thu, Jul 26, 2018 at 6:59 PM, Richard Smith <richard@metafoo.co.uk>
wrote:
> Also, the function parameters would not be in scope in an attribute
> appearing in that location.
>
>
> On Thu, 26 Jul 2018 at 15:03, Nicolas Lesser <blitzrakete@gmail.com>
> wrote:
>
>> Ah, didn't know that "appertain" means that. Thanks for correcting me :)
>>
>> On Thu, Jul 26, 2018 at 3:01 PM Nicol Bolas <jmckesson@gmail.com> wrote:
>>
>>>
>>>
>>> On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Nicolas Lesser wrote:
>>>>
>>>> Attributes with trailing return type generally suffer from this problem:
>>>>
>>>> auto f(int x, int y) [[deprecated]] -> int;
>>>>
>>>> If you don't mind, you can put the contracts before, just like we
>>>> normally do with attributes:
>>>>
>>>> [[expects: x>0]]
>>>> [[expects: y!=0]]
>>>> [[ensures result: result > x+y]]
>>>> auto f(int x, int y) -> int;
>>>>
>>>
>>> Not according to P0542. Contracts "appertain to the function type", so
>>> they can't be prefixed.
>>>
>>> --
>>> 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 email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/
>>> isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-
>>> a9ca-098f1ed8b380%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
>> 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
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> To view this discussion on the web visit https://groups.google.com/a/
>> isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_
>> -tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gmail.com
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BHT75HAfeRWY_sY0EAGw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/CAOfiQq%3D2%3DVuqbb6zRg3bjfr3_ZPWHO%
> 3D1cDXz1FsON%3DeAnNzf2w%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D2%3DVuqbb6zRg3bjfr3_ZPWHO%3D1cDXz1FsON%3DeAnNzf2w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
Be seeing you,
Tony
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuWjkdDOBstE4%3DqMUBrQfrRoU7wbo_-2UxQEESH2XP7ag%40mail.gmail.com.
--0000000000004b5c940571f0bd56
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>How does this compare to where `requires` goes?=C2=A0=
Is that before or after the trailing return?<br></div><div><br></div><div>=
Maybe contracts and requires should go next to each other? (One being compi=
le-time constraints, the other runtime.)<br></div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Thu, Jul 26, 2018 at 6:59 PM, Ric=
hard Smith <span dir=3D"ltr"><<a href=3D"mailto:richard@metafoo.co.uk" t=
arget=3D"_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">Also, the function parameters would no=
t be in scope in an attribute appearing in that location.<div><div class=3D=
"h5"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 26 Jul 201=
8 at 15:03, Nicolas Lesser <<a href=3D"mailto:blitzrakete@gmail.com" tar=
get=3D"_blank">blitzrakete@gmail.com</a>> wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Ah, didn't know that "appertain&=
quot; means that. Thanks for correcting me :)</div><br><div class=3D"gmail_=
quote"><div dir=3D"ltr">On Thu, Jul 26, 2018 at 3:01 PM Nicol Bolas <<a =
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>On Thursday, July 26, 2018 at 5:49:24 PM UTC-4, Nicolas Lesser wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Attributes with trai=
ling return type generally suffer from this problem:<div><br></div><div>aut=
o f(int x, int y) [[deprecated]] -> int;</div><div><br></div><div>If you=
don't mind, you can put the contracts before, just like we normally do=
with attributes:</div><div><br></div><div><div>[[expects: x>0]]</div><d=
iv>[[expects: y!=3D0]]</div><div>[[ensures result: result > x+y]]</div><=
/div><div>auto f(int x, int y) -> int;</div></div></blockquote><div><br>=
</div><div>Not according to P0542. Contracts "appertain to the functio=
n type", so they can't be prefixed.</div><br></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/08e4fce4-e6c6-4dc2-a9ca-098f1ed8b380%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/08e4=
fce4-e6c6-4dc2-<wbr>a9ca-098f1ed8b380%40isocpp.org</a><wbr>.<br>
</blockquote></div>
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CALmDwq1c8__QT0t3Xk_-tEE%2BnkuxP7%2BH=
T75HAfeRWY_sY0EAGw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/=
std-<wbr>proposals/CALmDwq1c8__QT0t3Xk_<wbr>-tEE%2BnkuxP7%2BHT75HAfeRWY_<wb=
r>sY0EAGw%40mail.gmail.com</a>.<br>
</blockquote></div></div></div></div><div><div class=3D"h5">
<p></p>
-- <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" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D2%3DVuqbb6zRg3bjfr3_ZPWHO%3=
D1cDXz1FsON%3DeAnNzf2w%40mail.gmail.com?utm_medium=3Demail&utm_source=
=3Dfooter" target=3D"_blank">https://groups.google.com/a/<wbr>isocpp.org/d/=
msgid/std-<wbr>proposals/CAOfiQq%3D2%<wbr>3DVuqbb6zRg3bjfr3_ZPWHO%<wbr>3D1c=
DXz1FsON%3DeAnNzf2w%<wbr>40mail.gmail.com</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></div></div>
</div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuWjkdDOBstE4%3DqMUBrQfrRoU7wbo=
_-2UxQEESH2XP7ag%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbiuWjkdDOB=
stE4%3DqMUBrQfrRoU7wbo_-2UxQEESH2XP7ag%40mail.gmail.com</a>.<br />
--0000000000004b5c940571f0bd56--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 26 Jul 2018 20:59:24 -0700 (PDT)
Raw View
------=_Part_10469_203361761.1532663964246
Content-Type: multipart/alternative;
boundary="----=_Part_10470_366798326.1532663964246"
------=_Part_10470_366798326.1532663964246
Content-Type: text/plain; charset="UTF-8"
On Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E wrote:
>
> How does this compare to where `requires` goes? Is that before or after
> the trailing return?
>
It appears to be after the whole thing, including the trailing return. It
seems to be:
Identifier/auto function_name(...) cv_qualifiers &/&& noexcept attributes
trailing-return-type requires-clause
C++'s syntax is a huge mess...
--
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 email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f0dac9d7-d139-4056-bf7f-bcad493436e0%40isocpp.org.
------=_Part_10470_366798326.1532663964246
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E w=
rote:<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>How=
does this compare to where `requires` goes?=C2=A0 Is that before or after =
the trailing return?<br></div></div></blockquote><div><br></div><div>It app=
ears to be after the whole thing, including the trailing return. It seems t=
o be:</div><div><br></div><div>Identifier/auto function_name(...) cv_qualif=
iers &/&& noexcept attributes trailing-return-type requires-cla=
use</div><div><br></div><div>C++'s syntax is a huge mess...<br></div></=
div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f0dac9d7-d139-4056-bf7f-bcad493436e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f0dac9d7-d139-4056-bf7f-bcad493436e0=
%40isocpp.org</a>.<br />
------=_Part_10470_366798326.1532663964246--
------=_Part_10469_203361761.1532663964246--
.
Author: "'Hamza Sood' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Tue, 31 Jul 2018 12:08:40 -0700 (PDT)
Raw View
------=_Part_11564_1394178166.1533064120174
Content-Type: multipart/alternative;
boundary="----=_Part_11565_840912426.1533064120174"
------=_Part_11565_840912426.1533064120174
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Would anything break if a dedicated contract-specifier-seq was added after=
=20
the requires-clause?
It feels really messy having contracts interrupt the function type like=20
that, especially when they don=E2=80=99t really have anything to do with it=
=20
(semantically anyway).
On Friday, July 27, 2018 at 4:59:24 AM UTC+1, Nicol Bolas wrote:
>
> On Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E wrote:
>>
>> How does this compare to where `requires` goes? Is that before or after=
=20
>> the trailing return?
>>
>
> It appears to be after the whole thing, including the trailing return. It=
=20
> seems to be:
>
> Identifier/auto function_name(...) cv_qualifiers &/&& noexcept attributes=
=20
> trailing-return-type requires-clause
>
> C++'s syntax is a huge mess...
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c787e7ba-9c65-429b-9d53-ba8af7998963%40isocpp.or=
g.
------=_Part_11565_840912426.1533064120174
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Would anything break if a dedicated contract-specifie=
r-seq was added after the requires-clause?</div><div><br></div><div>It feel=
s really messy having contracts interrupt the function type like that, espe=
cially when they don=E2=80=99t really have anything to do with it (semantic=
ally anyway).</div><br>On Friday, July 27, 2018 at 4:59:24 AM UTC+1, Nicol =
Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E wrote:<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"><div>How does this compare to w=
here `requires` goes?=C2=A0 Is that before or after the trailing return?<br=
></div></div></blockquote><div><br></div><div>It appears to be after the wh=
ole thing, including the trailing return. It seems to be:</div><div><br></d=
iv><div>Identifier/auto function_name(...) cv_qualifiers &/&& n=
oexcept attributes trailing-return-type requires-clause</div><div><br></div=
><div>C++'s syntax is a huge mess...<br></div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c787e7ba-9c65-429b-9d53-ba8af7998963%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c787e7ba-9c65-429b-9d53-ba8af7998963=
%40isocpp.org</a>.<br />
------=_Part_11565_840912426.1533064120174--
------=_Part_11564_1394178166.1533064120174--
.
Author: "T. C." <rs2740@gmail.com>
Date: Wed, 1 Aug 2018 15:16:47 -0700 (PDT)
Raw View
------=_Part_153_1708354042.1533161807254
Content-Type: multipart/alternative;
boundary="----=_Part_154_884429392.1533161807254"
------=_Part_154_884429392.1533161807254
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
When there's no requires-clause, an attribute at that location already has=
=20
a meaning: it appertains to some portion of the return type. For example:
auto f() -> int [[meow]]; // [[meow]] is part of the type-specifier-seq;=
=20
appertains to the type "int".
auto y() -> int(*)() [[purr]]; // [[purr]] appertains to the type int().
On Tuesday, July 31, 2018 at 3:08:40 PM UTC-4, Hamza Sood wrote:
>
> Would anything break if a dedicated contract-specifier-seq was added afte=
r=20
> the requires-clause?
>
> It feels really messy having contracts interrupt the function type like=
=20
> that, especially when they don=E2=80=99t really have anything to do with =
it=20
> (semantically anyway).
>
> On Friday, July 27, 2018 at 4:59:24 AM UTC+1, Nicol Bolas wrote:
>>
>> On Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E wrote:
>>>
>>> How does this compare to where `requires` goes? Is that before or afte=
r=20
>>> the trailing return?
>>>
>>
>> It appears to be after the whole thing, including the trailing return. I=
t=20
>> seems to be:
>>
>> Identifier/auto function_name(...) cv_qualifiers &/&& noexcept attribute=
s=20
>> trailing-return-type requires-clause
>>
>> C++'s syntax is a huge mess...
>>
>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9dd24044-8886-4b01-8724-0586b5ed1f55%40isocpp.or=
g.
------=_Part_154_884429392.1533161807254
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">When there's no requires-clause, an attribute at that =
location already has a meaning: it appertains to some portion of the return=
type. For example:<div><div><br></div><div>auto f() -> int [[meow]];=C2=
=A0 // [[meow]] is part of the type-specifier-seq; appertains to the type &=
quot;int".</div><div>auto y() -> int(*)() [[purr]]; // [[purr]] app=
ertains to the type int().</div><div><br></div><div><div>On Tuesday, July 3=
1, 2018 at 3:08:40 PM UTC-4, Hamza Sood wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>Would anything break if a dedicated c=
ontract-specifier-seq was added after the requires-clause?</div><div><br></=
div><div>It feels really messy having contracts interrupt the function type=
like that, especially when they don=E2=80=99t really have anything to do w=
ith it (semantically anyway).</div><br>On Friday, July 27, 2018 at 4:59:24 =
AM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">On Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>How does this c=
ompare to where `requires` goes?=C2=A0 Is that before or after the trailing=
return?<br></div></div></blockquote><div><br></div><div>It appears to be a=
fter the whole thing, including the trailing return. It seems to be:</div><=
div><br></div><div>Identifier/auto function_name(...) cv_qualifiers &/&=
amp;& noexcept attributes trailing-return-type requires-clause</div><di=
v><br></div><div>C++'s syntax is a huge mess...<br></div></div></blockq=
uote></div></blockquote></div></div></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9dd24044-8886-4b01-8724-0586b5ed1f55%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9dd24044-8886-4b01-8724-0586b5ed1f55=
%40isocpp.org</a>.<br />
------=_Part_154_884429392.1533161807254--
------=_Part_153_1708354042.1533161807254--
.
Author: "'Hamza Sood' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Thu, 2 Aug 2018 11:51:24 -0700 (PDT)
Raw View
------=_Part_373_1589672321.1533235884673
Content-Type: multipart/alternative;
boundary="----=_Part_374_99762319.1533235884673"
------=_Part_374_99762319.1533235884673
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Right, but the current placement also conflicts with an existing meaning:=
=20
attributes at that location appertain to the function type.
On Wednesday, August 1, 2018 at 11:16:47 PM UTC+1, T. C. wrote:
>
> When there's no requires-clause, an attribute at that location already ha=
s=20
> a meaning: it appertains to some portion of the return type. For example:
>
> auto f() -> int [[meow]]; // [[meow]] is part of the type-specifier-seq;=
=20
> appertains to the type "int".
> auto y() -> int(*)() [[purr]]; // [[purr]] appertains to the type int().
>
> On Tuesday, July 31, 2018 at 3:08:40 PM UTC-4, Hamza Sood wrote:
>>
>> Would anything break if a dedicated contract-specifier-seq was added=20
>> after the requires-clause?
>>
>> It feels really messy having contracts interrupt the function type like=
=20
>> that, especially when they don=E2=80=99t really have anything to do with=
it=20
>> (semantically anyway).
>>
>> On Friday, July 27, 2018 at 4:59:24 AM UTC+1, Nicol Bolas wrote:
>>>
>>> On Thursday, July 26, 2018 at 9:07:47 PM UTC-4, Tony V E wrote:
>>>>
>>>> How does this compare to where `requires` goes? Is that before or=20
>>>> after the trailing return?
>>>>
>>>
>>> It appears to be after the whole thing, including the trailing return.=
=20
>>> It seems to be:
>>>
>>> Identifier/auto function_name(...) cv_qualifiers &/&& noexcept=20
>>> attributes trailing-return-type requires-clause
>>>
>>> C++'s syntax is a huge mess...
>>>
>>
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c46dda85-6994-464b-b505-0a712ce51cb4%40isocpp.or=
g.
------=_Part_374_99762319.1533235884673
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Right, but the current placement also conflicts with an ex=
isting meaning: attributes at that location appertain to the function type.=
<br><br>On Wednesday, August 1, 2018 at 11:16:47 PM UTC+1, T. C. wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">When there's =
no requires-clause, an attribute at that location already has a meaning: it=
appertains to some portion of the return type. For example:<div><div><br><=
/div><div>auto f() -> int [[meow]];=C2=A0 // [[meow]] is part of the typ=
e-specifier-seq; appertains to the type "int".</div><div>auto y()=
-> int(*)() [[purr]]; // [[purr]] appertains to the type int().</div><d=
iv><br></div><div><div>On Tuesday, July 31, 2018 at 3:08:40 PM UTC-4, Hamza=
Sood wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>W=
ould anything break if a dedicated contract-specifier-seq was added after t=
he requires-clause?</div><div><br></div><div>It feels really messy having c=
ontracts interrupt the function type like that, especially when they don=E2=
=80=99t really have anything to do with it (semantically anyway).</div><br>=
On Friday, July 27, 2018 at 4:59:24 AM UTC+1, Nicol Bolas wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, July 26, 2018 at=
9:07:47 PM UTC-4, Tony V E wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>How does this compare to where `requires` goes?=C2=
=A0 Is that before or after the trailing return?<br></div></div></blockquot=
e><div><br></div><div>It appears to be after the whole thing, including the=
trailing return. It seems to be:</div><div><br></div><div>Identifier/auto =
function_name(...) cv_qualifiers &/&& noexcept attributes trail=
ing-return-type requires-clause</div><div><br></div><div>C++'s syntax i=
s a huge mess...<br></div></div></blockquote></div></blockquote></div></div=
></div></div></blockquote></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c46dda85-6994-464b-b505-0a712ce51cb4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c46dda85-6994-464b-b505-0a712ce51cb4=
%40isocpp.org</a>.<br />
------=_Part_374_99762319.1533235884673--
------=_Part_373_1589672321.1533235884673--
.
Author: Alberto Barbati <albertobarbati@gmail.com>
Date: Fri, 3 Aug 2018 01:54:35 -0700 (PDT)
Raw View
------=_Part_571_23024191.1533286475645
Content-Type: multipart/alternative;
boundary="----=_Part_572_94556748.1533286475645"
------=_Part_572_94556748.1533286475645
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Il giorno gioved=C3=AC 2 agosto 2018 20:51:24 UTC+2, Hamza Sood ha scritto:
>
> Right, but the current placement also conflicts with an existing meaning:=
=20
> attributes at that location appertain to the function type.
>
I don't see where is the conflict since contracts appertain to the function=
=20
type, not to the function. See [dcl.attr.contracts]/6: "A contract=20
condition may be applied to the function type of a function declaration.".=
=20
See also section 2.2 of http://wg21.link/P0542
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/41297ed8-df8b-4802-b914-cc567bea8fb3%40isocpp.or=
g.
------=_Part_572_94556748.1533286475645
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Il giorno gioved=C3=AC 2 agosto 2018 20:51:24 UTC+2, Hamza=
Sood ha scritto:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Right, but the current placement also conflicts with an existing meanin=
g: attributes at that location appertain to the function type.<br></div></b=
lockquote><div><br></div><div>I don't see where is the conflict since c=
ontracts appertain to the function type, not to the function. See [dcl.attr=
..contracts]/6: "A contract condition may be applied to the function ty=
pe of a function declaration.". See also section 2.2 of <a href=3D"htt=
p://wg21.link/P0542">http://wg21.link/P0542</a><br></div></div>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/41297ed8-df8b-4802-b914-cc567bea8fb3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/41297ed8-df8b-4802-b914-cc567bea8fb3=
%40isocpp.org</a>.<br />
------=_Part_572_94556748.1533286475645--
------=_Part_571_23024191.1533286475645--
.
Author: "hamza_sood via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Mon, 13 Aug 2018 09:22:00 -0700 (PDT)
Raw View
------=_Part_1538_1295906219.1534177320108
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
It=E2=80=99s a conflict in that the actual meaning of attributes in that lo=
cation is ignored: contracts are (semantically) unrelated to the function t=
ype. I=E2=80=99m just suggesting that it=E2=80=99s moved from one unrelated=
location to another.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/aa64fbc0-eb30-4a35-83d5-268fa9fe9b8a%40isocpp.or=
g.
------=_Part_1538_1295906219.1534177320108--
.