------=_Part_751_1464020623.1533906841596
Content-Type: multipart/alternative;
 boundary="----=_Part_752_206101752.1533906841596"

------=_Part_752_206101752.1533906841596
Content-Type: text/plain; charset="UTF-8"

I agree constexpr is distracting, but no one will go ahead with such a
change just for readability, especially considering there will be people
who will like the old one better and will be back at const-before-or-after.

--
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/42220a50-c645-4082-9c7b-c7d1c2ea51b3%40isocpp.org.

------=_Part_752_206101752.1533906841596
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I agree <font face=3D"courier new,monospace">constexpr</fo=
nt> is distracting, but no one will go ahead with such a change just for re=
adability, especially considering there will be people who will like the ol=
d one better and will be back at const-before-or-after.</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/42220a50-c645-4082-9c7b-c7d1c2ea51b3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42220a50-c645-4082-9c7b-c7d1c2ea51b3=
%40isocpp.org</a>.<br />

------=_Part_752_206101752.1533906841596--

------=_Part_751_1464020623.1533906841596--

.

------=_Part_744_312476192.1533915330810
Content-Type: multipart/alternative;
 boundary="----=_Part_745_825711786.1533915330810"

------=_Part_745_825711786.1533915330810
Content-Type: text/plain; charset="UTF-8"



On Friday, August 10, 2018 at 7:51:13 AM UTC-5, Dimitrij Mijoski wrote:
>
> This proposal is strictly about syntax, its goal is to get better
> readability.
>
> In C++11 there was an excellent improvements with this regard with auto
> variables, trailing return function syntax and with using. But since then,
> we kinda forgot on this aspect. These syntax features gave left-to-right
> reading, i.e. the code reads the same way one would read it on English.
>
> One concern I have is the syntax for function declaration. Currently we
> have:
>
> left keywords Type function_name(Parameter list) right keywords;
> auto left keywords function_name(Parameter list) right keywords -> Type;
> left keywords auto function_name(Parameter list) right keywords -> Type;
>
> Left keywords are: static, virtual and constexpr.
> Right are: const, &, &&, virtual, override, final, noexcept.
>
> I'm mostly concerned about constexpr getting sprayed all over the standard
> library. On cppreference.com you often see:
>
> Type func(Param p1, Param p2, Param p3);           (until C++17)
> constexpr Type func(Param p1, Param p2, Param p3); (since C++20)
>
> Even the documentation is harder to read now. I'd like to see the "one
> true" function definition syntax to go like this:
>
> auto function_name(Param p1, Param p2, Param p3) all keywords here [[attributes
> here]] -> Type;
>
> Why limit this to functions?  Why not a variable declaration like this:
auto variable_name all keywords here [[attributes here]] -> Type;


--
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/be072741-3b67-43de-b7e8-634253932a95%40isocpp.org.

------=_Part_745_825711786.1533915330810
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 10, 2018 at 7:51:13 AM UTC-5, Di=
mitrij Mijoski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">This proposal is strictly about syntax, its goal is to get better =
readability.<br><br>In C++11 there was an excellent improvements with this =
regard with auto variables, trailing return function syntax and with using.=
 But since then, we kinda forgot on this aspect. These syntax features gave=
 left-to-right reading, i.e. the code reads the same way one would read it =
on English.<br><br>One concern I have is the syntax for function declaratio=
n. Currently we have:<br><br><div style=3D"background-color:rgb(250,250,250=
);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><code>=
<div><span style=3D"color:#000">left keywords </span><span style=3D"color:#=
606">Type</span><span style=3D"color:#000"> function_name</span><span style=
=3D"color:#660">(</span><span style=3D"color:#606">Parameter</span><span st=
yle=3D"color:#000"> list</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"> right keywords</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#008">auto</span=
><span style=3D"color:#000"> left keywords function_name</span><span style=
=3D"color:#660">(</span><span style=3D"color:#606">Parameter</span><span st=
yle=3D"color:#000"> list</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"> right keywords </span><span style=3D"color:#660">-&gt;</=
span><span style=3D"color:#000"> </span><span style=3D"color:#606">Type</sp=
an><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>left k=
eywords </span><span style=3D"color:#008">auto</span><span style=3D"color:#=
000"> function_name</span><span style=3D"color:#660">(</span><span style=3D=
"color:#606">Parameter</span><span style=3D"color:#000"> list</span><span s=
tyle=3D"color:#660">)</span><span style=3D"color:#000"> right keywords </sp=
an><span style=3D"color:#660">-&gt;</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">Type</span><span style=3D"color:#660">;</span>=
</div></code></div><div><br></div><div>Left keywords are: static, virtual a=
nd constexpr.</div>Right are: const, &amp;, &amp;&amp;, virtual, override, =
final, noexcept.<br><br>I&#39;m mostly concerned about constexpr getting sp=
rayed all over the standard library. On <a href=3D"http://cppreference.com"=
 target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://=
www.google.com/url?q\x3dhttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug&#39;;return true;" onclick=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fcppreferen=
ce.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug=
&#39;;return true;">cppreference.com</a> you often see:<br><br><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px"><code><div><span style=3D"color:#606">Type</s=
pan><span style=3D"color:#000"> func</span><span style=3D"color:#660">(</sp=
an><span style=3D"color:#606">Param</span><span style=3D"color:#000"> p1</s=
pan><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">Param</span><span style=3D"color:#000"> p2</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span=
 style=3D"color:#606">Param</span><span style=3D"color:#000"> p3</span><spa=
n style=3D"color:#660">);</span><span style=3D"color:#000"> =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">until</span><span style=3D"color:#000"> C</span><span style=
=3D"color:#660">++</span><span style=3D"color:#066">17</span><span style=3D=
"color:#660">)</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#008">constexpr</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Type</span><span style=3D"color:#000"> func</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#606">Param</span><span styl=
e=3D"color:#000"> p1</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Param</span><span style=
=3D"color:#000"> p2</span><span style=3D"color:#660">,</span><span style=3D=
"color:#000"> </span><span style=3D"color:#606">Param</span><span style=3D"=
color:#000"> p3</span><span style=3D"color:#660">);</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">since C</span><span style=3D"color:#660">++</span><span style=3D"color=
:#066">20</span><span style=3D"color:#660">)</span></div></code></div><br>E=
ven the documentation is harder to read now. I&#39;d like to see the &quot;=
one true&quot; function definition syntax to go like this:<br><br><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px"><code><div><span style=3D"color:#008">auto</=
span><span style=3D"color:#000"> function_name</span><span style=3D"color:#=
660">(</span><span style=3D"color:#606">Param</span><span style=3D"color:#0=
00"> p1</span><span style=3D"color:#660">,</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">Param</span><span style=3D"color:#000">=
 p2</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </=
span><span style=3D"color:#606">Param</span><span style=3D"color:#000"> p3<=
/span><span style=3D"color:#660">)</span><span style=3D"color:#000"> all ke=
ywords here </span><span style=3D"color:#660">[[</span><span style=3D"color=
:#000">attributes here</span><span style=3D"color:#660">]]</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#606">Type</span><span style=
=3D"color:#660">;</span></div></code></div><br></div></blockquote><div>Why =
limit this to functions?=C2=A0 Why not a variable declaration like this:</d=
iv><div> <div style=3D"background-color: rgb(250, 250, 250); border-color: =
rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: =
break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> va=
riable_name all keywords here </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">[[</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">attributes here</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">]]</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/be072741-3b67-43de-b7e8-634253932a95%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/be072741-3b67-43de-b7e8-634253932a95=
%40isocpp.org</a>.<br />

------=_Part_745_825711786.1533915330810--

------=_Part_744_312476192.1533915330810--

.

------=_Part_1058_835843091.1534011713292
Content-Type: multipart/alternative;
 boundary="----=_Part_1059_939413287.1534011713292"

------=_Part_1059_939413287.1534011713292
Content-Type: text/plain; charset="UTF-8"

On Friday, August 10, 2018 at 5:35:30 PM UTC+2, cpplj...@gmail.com wrote:
>
>
> Why limit this to functions?  Why not a variable declaration like this:
> auto variable_name all keywords here [[attributes here]] -> Type;
>
> For variables i'd use a colon (:) instead of arrow. Colon after variable
name is common in other programming languages, i created a separate thread
on this mailing list for variables. I'd go for something like this:
auto x = Type(); // with type inference
const auto& y = func_returning_reference(); // with type inference

auto z: Type; // explicit type
auto w: Type2 = Type2(); // explicit type, and assignment
auto& u: Type = ..; // INVALID, only plain auto when explicitly setting type

//with additional keywords
auto t static thread_local constexpr = Type(); // with inference
auto v: Type static thread_local constexpr; //explicit type


--
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/dd2e815d-e68b-4b63-a86d-0e42f8b4a974%40isocpp.org.

------=_Part_1059_939413287.1534011713292
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, August 10, 2018 at 5:35:30 PM UTC+2, cpplj...@g=
mail.com 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=
"><br><div>Why limit this to functions?=C2=A0 Why not a variable declaratio=
n like this:</div><div> <div style=3D"background-color:rgb(250,250,250);bor=
der-color:rgb(187,187,187);border-style:solid;border-width:1px"><code><div>=
<span style=3D"color:#008">auto</span><span style=3D"color:#000"> variable_=
name all keywords here </span><span style=3D"color:#660">[[</span><span sty=
le=3D"color:#000">attributes here</span><span style=3D"color:#660">]]</span=
><span style=3D"color:#000"> </span><span style=3D"color:#660">-&gt;</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">Type</span><s=
pan style=3D"color:#660">;</span><span style=3D"color:#000"><br></span></di=
v></code></div><br></div></div></blockquote><div>For variables i&#39;d use =
a colon (:) instead of arrow. Colon after variable name is common in other =
programming languages, i created a separate thread on this mailing list for=
 variables. I&#39;d go for something like this:</div><div><div style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"pret=
typrint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Type</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ with type inference</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> y </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> func_returning_reference</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">// with type inference</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> z</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Type</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// exp=
licit type</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><code =
class=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
w</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">Type2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify"> =3D Type2();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #800;" class=3D"styled-by-prettify">// explicit type</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">, and assignment<br></span></co=
de></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> u</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Type =3D ..; // INVALID, only plain auto whe=
n explicitly setting type</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br>//with additional keywords<br>auto t static thread_l=
ocal constexpr =3D Type(); // with inference<br>auto v: Type </span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypri=
nt"><span style=3D"color: #000;" class=3D"styled-by-prettify">static thread=
_local constexpr; //explicit type<br></span></code></span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettypr=
int"><span style=3D"color: #660;" class=3D"styled-by-prettify"></span></cod=
e></span></code></span></div></code></div><br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/dd2e815d-e68b-4b63-a86d-0e42f8b4a974%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd2e815d-e68b-4b63-a86d-0e42f8b4a974=
%40isocpp.org</a>.<br />

------=_Part_1059_939413287.1534011713292--

------=_Part_1058_835843091.1534011713292--

.

------=_Part_1876_2001100767.1534243389869
Content-Type: multipart/alternative;
 boundary="----=_Part_1877_485746898.1534243389869"

------=_Part_1877_485746898.1534243389869
Content-Type: text/plain; charset="UTF-8"

On reddit today this popped: What do you think about long functions
declarations?
<https://www.reddit.com/r/cpp/comments/975h3d/what_do_you_think_about_long_functions/>
There are other people that are concerned about readability and see a
problem there.

On Friday, August 10, 2018 at 2:51:13 PM UTC+2, Dimitrij Mijoski wrote:
>
> This proposal is strictly about syntax, its goal is to get better
> readability.
>
> In C++11 there was an excellent improvements with this regard with auto
> variables, trailing return function syntax and with using. But since then,
> we kinda forgot on this aspect. These syntax features gave left-to-right
> reading, i.e. the code reads the same way one would read it on English.
>
> One concern I have is the syntax for function declaration. Currently we
> have:
>
> left keywords Type function_name(Parameter list) right keywords;
> auto left keywords function_name(Parameter list) right keywords -> Type;
> left keywords auto function_name(Parameter list) right keywords -> Type;
>
> Left keywords are: static, virtual and constexpr.
> Right are: const, &, &&, virtual, override, final, noexcept.
>
> I'm mostly concerned about constexpr getting sprayed all over the standard
> library. On cppreference.com you often see:
>
> Type func(Param p1, Param p2, Param p3);           (until C++17)
> constexpr Type func(Param p1, Param p2, Param p3); (since C++20)
>
> Even the documentation is harder to read now. I'd like to see the "one
> true" function definition syntax to go like this:
>
> auto function_name(Param p1, Param p2, Param p3) all keywords here [[attributes
> here]] -> Type;
>
>

--
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/7f49d619-718f-4e5c-9f49-e63cf689d040%40isocpp.org.

------=_Part_1877_485746898.1534243389869
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On reddit today this popped: <a href=3D"https://www.r=
eddit.com/r/cpp/comments/975h3d/what_do_you_think_about_long_functions/">Wh=
at do you think about long functions declarations?</a></div>There are other=
 people that are concerned about readability and see a problem there.<br><b=
r>On Friday, August 10, 2018 at 2:51:13 PM UTC+2, Dimitrij Mijoski wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This proposal i=
s strictly about syntax, its goal is to get better readability.<br><br>In C=
++11 there was an excellent improvements with this regard with auto variabl=
es, trailing return function syntax and with using. But since then, we kind=
a forgot on this aspect. These syntax features gave left-to-right reading, =
i.e. the code reads the same way one would read it on English.<br><br>One c=
oncern I have is the syntax for function declaration. Currently we have:<br=
><br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px"><code><div><span style=3D"colo=
r:#000">left keywords </span><span style=3D"color:#606">Type</span><span st=
yle=3D"color:#000"> function_name</span><span style=3D"color:#660">(</span>=
<span style=3D"color:#606">Parameter</span><span style=3D"color:#000"> list=
</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> right=
 keywords</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"><br></span><span style=3D"color:#008">auto</span><span style=3D"color:#0=
00"> left keywords function_name</span><span style=3D"color:#660">(</span><=
span style=3D"color:#606">Parameter</span><span style=3D"color:#000"> list<=
/span><span style=3D"color:#660">)</span><span style=3D"color:#000"> right =
keywords </span><span style=3D"color:#660">-&gt;</span><span style=3D"color=
:#000"> </span><span style=3D"color:#606">Type</span><span style=3D"color:#=
660">;</span><span style=3D"color:#000"><br>left keywords </span><span styl=
e=3D"color:#008">auto</span><span style=3D"color:#000"> function_name</span=
><span style=3D"color:#660">(</span><span style=3D"color:#606">Parameter</s=
pan><span style=3D"color:#000"> list</span><span style=3D"color:#660">)</sp=
an><span style=3D"color:#000"> right keywords </span><span style=3D"color:#=
660">-&gt;</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
06">Type</span><span style=3D"color:#660">;</span></div></code></div><div><=
br></div><div>Left keywords are: static, virtual and constexpr.</div>Right =
are: const, &amp;, &amp;&amp;, virtual, override, final, noexcept.<br><br>I=
&#39;m mostly concerned about constexpr getting sprayed all over the standa=
rd library. On <a href=3D"http://cppreference.com" target=3D"_blank" rel=3D=
"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dh=
ttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFfMEVs=
riPdiSLWG49XWK9zX_c5Ug&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\x3dhttp%3A%2F%2Fcppreference.com\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNFfMEVsriPdiSLWG49XWK9zX_c5Ug&#39;;return true;">cppref=
erence.com</a> you often see:<br><br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
"><code><div><span style=3D"color:#606">Type</span><span style=3D"color:#00=
0"> func</span><span style=3D"color:#660">(</span><span style=3D"color:#606=
">Param</span><span style=3D"color:#000"> p1</span><span style=3D"color:#66=
0">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Pa=
ram</span><span style=3D"color:#000"> p2</span><span style=3D"color:#660">,=
</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Param<=
/span><span style=3D"color:#000"> p3</span><span style=3D"color:#660">);</s=
pan><span style=3D"color:#000"> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><=
span style=3D"color:#660">(</span><span style=3D"color:#008">until</span><s=
pan style=3D"color:#000"> C</span><span style=3D"color:#660">++</span><span=
 style=3D"color:#066">17</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#008">constexpr</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#606">Type</span><span=
 style=3D"color:#000"> func</span><span style=3D"color:#660">(</span><span =
style=3D"color:#606">Param</span><span style=3D"color:#000"> p1</span><span=
 style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#606">Param</span><span style=3D"color:#000"> p2</span><span sty=
le=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D=
"color:#606">Param</span><span style=3D"color:#000"> p3</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">(</span><span style=3D"color:#000">since C</span><span style=3D=
"color:#660">++</span><span style=3D"color:#066">20</span><span style=3D"co=
lor:#660">)</span></div></code></div><br>Even the documentation is harder t=
o read now. I&#39;d like to see the &quot;one true&quot; function definitio=
n syntax to go like this:<br><br><div style=3D"background-color:rgb(250,250=
,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px"><c=
ode><div><span style=3D"color:#008">auto</span><span style=3D"color:#000"> =
function_name</span><span style=3D"color:#660">(</span><span style=3D"color=
:#606">Param</span><span style=3D"color:#000"> p1</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#60=
6">Param</span><span style=3D"color:#000"> p2</span><span style=3D"color:#6=
60">,</span><span style=3D"color:#000"> </span><span style=3D"color:#606">P=
aram</span><span style=3D"color:#000"> p3</span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> all keywords here </span><span style=3D=
"color:#660">[[</span><span style=3D"color:#000">attributes here</span><spa=
n style=3D"color:#660">]]</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">-&gt;</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#606">Type</span><span style=3D"color:#660">;</span></div></cod=
e></div><br></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7f49d619-718f-4e5c-9f49-e63cf689d040%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f49d619-718f-4e5c-9f49-e63cf689d040=
%40isocpp.org</a>.<br />

------=_Part_1877_485746898.1534243389869--

------=_Part_1876_2001100767.1534243389869--

.

------=_Part_1841_1561205855.1534253290461
Content-Type: multipart/alternative;
 boundary="----=_Part_1842_689578414.1534253290461"

------=_Part_1842_689578414.1534253290461
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 14, 2018 at 6:43:09 AM UTC-4, Dimitrij Mijoski wrote:
>
> On reddit today this popped: What do you think about long functions
> declarations?
> <https://www.reddit.com/r/cpp/comments/975h3d/what_do_you_think_about_long_functions/>
> There are other people that are concerned about readability and see a
> problem there.
>

Yes, but those are talking about *length*; nothing you've proposed here
would make function declarations shorter. Your proposal simply rearranges
where stuff goes, not how much stuff needs to go there.

--
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/6588d11a-8353-4df1-8f22-85cf54b2d553%40isocpp.org.

------=_Part_1842_689578414.1534253290461
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 14, 2018 at 6:43:09 AM UTC-4, Dimitrij =
Mijoski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>On reddit today this popped: <a href=3D"https://www.reddit.com/r/cpp/=
comments/975h3d/what_do_you_think_about_long_functions/" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url=
?q\x3dhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fcpp%2Fcomments%2F975h3d%2Fwhat_do_=
you_think_about_long_functions%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNE=
zi5meopr7pcvErw45XOo6fNNWOQ&#39;;return true;" onclick=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fwww.reddit.com%2Fr%2Fcpp%2Fco=
mments%2F975h3d%2Fwhat_do_you_think_about_long_functions%2F\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNEzi5meopr7pcvErw45XOo6fNNWOQ&#39;;return true;">Wh=
at do you think about long functions declarations?</a></div>There are other=
 people that are concerned about readability and see a problem there.<br></=
div></blockquote><div><br></div><div>Yes, but those are talking about <i>le=
ngth</i>; nothing you&#39;ve proposed here would make function declarations=
 shorter. Your proposal simply rearranges where stuff goes, not how much st=
uff needs to go there.</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6588d11a-8353-4df1-8f22-85cf54b2d553%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6588d11a-8353-4df1-8f22-85cf54b2d553=
%40isocpp.org</a>.<br />

------=_Part_1842_689578414.1534253290461--

------=_Part_1841_1561205855.1534253290461--

.

------=_Part_2111_2045775251.1534268743464
Content-Type: multipart/alternative;
 boundary="----=_Part_2112_949145111.1534268743464"

------=_Part_2112_949145111.1534268743464
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 14, 2018 at 3:28:10 PM UTC+2, Nicol Bolas wrote:

>
> Yes, but those are talking about *length*; nothing you've proposed here
> would make function declarations shorter. Your proposal simply rearranges
> where stuff goes, not how much stuff needs to go there.
>
>
Order matters for readability, too.

--
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/ef49ff5b-d23b-45c1-a884-c4fc40bfc0b2%40isocpp.org.

------=_Part_2112_949145111.1534268743464
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 14, 2018 at 3:28:10 PM UTC+2, Nicol Bol=
as wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br></div><div>Yes, but those are talking about <i>length</i>; nothing=
 you&#39;ve proposed here would make function declarations shorter. Your pr=
oposal simply rearranges where stuff goes, not how much stuff needs to go t=
here.</div><br></div></blockquote><div><br></div><div>Order matters for rea=
dability, too.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ef49ff5b-d23b-45c1-a884-c4fc40bfc0b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef49ff5b-d23b-45c1-a884-c4fc40bfc0b2=
%40isocpp.org</a>.<br />

------=_Part_2112_949145111.1534268743464--

------=_Part_2111_2045775251.1534268743464--

.

------=_Part_2075_1036184253.1534280447053
Content-Type: multipart/alternative;
 boundary="----=_Part_2076_1283907027.1534280447054"

------=_Part_2076_1283907027.1534280447054
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 14, 2018 at 1:45:43 PM UTC-4, Dimitrij Mijoski wrote:
>
> On Tuesday, August 14, 2018 at 3:28:10 PM UTC+2, Nicol Bolas wrote:
>
>>
>> Yes, but those are talking about *length*; nothing you've proposed here
>> would make function declarations shorter. Your proposal simply rearranges
>> where stuff goes, not how much stuff needs to go there.
>>
>>
> Order matters for readability, too.
>

I don't see how that changes the point. You posted a link to a discussion
that is ultimately irrelevant to the point of what you want. They want
function declarations to be shorter. You want them to be declared with
stuff in a different order.

These aren't the same thing.

However, it should also be noted that the order things are put in is not
arbitrary. There is a reason why `static`, `explicit`, `virtual` and
`constexpr` come first, and `noexcept` and the rest come last.

The keywords that come before function declarations define a fundamental
aspect of that function. `static` affects the function's linkage.
`explicit` affects when you can call it. `virtual` affects how that
function interacts with base/derived class functions with the same
parameters. `constexpr` affects when you can call the function.

By contrast, `noexcept` changes nothing about when you may call the
function. Even from within a `noexcept` function, you can call
non-`noexcept` functions. The `&/&&/cv-qualifier` suffixes are effectively
qualifiers to the implicit-`this` parameter of the function. They do affect
when you can call the function, but they affect it the way any function
parameter would, not in specialized ways like `static` and `constexpr`.

So it's not like which things are prefixes and which are suffixes is
entirely arbitrary. There is at least some logic to why some come first and
others come later.

So at the end of the day, I do not see how your suggestion improves
readability.

--
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/209ffbde-2a77-460d-ab23-24a869d549d0%40isocpp.org.

------=_Part_2076_1283907027.1534280447054
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 14, 2018 at 1:45:43 PM UTC-4, Dimitrij =
Mijoski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Tuesday, August 14, 2018 at 3:28:10 PM UTC+2, Nicol Bolas wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Y=
es, but those are talking about <i>length</i>; nothing you&#39;ve proposed =
here would make function declarations shorter. Your proposal simply rearran=
ges where stuff goes, not how much stuff needs to go there.</div><br></div>=
</blockquote><div><br></div><div>Order matters for readability, too.<br></d=
iv></div></blockquote><div><br></div><div>I don&#39;t see how that changes =
the point. You posted a link to a discussion that is ultimately irrelevant =
to the point of what you want. They want function declarations to be shorte=
r. You want them to be declared with stuff in a different order.</div><div>=
<br></div><div>These aren&#39;t the same thing.</div><div><br></div><div>Ho=
wever, it should also be noted that the order things are put in is not arbi=
trary. There is a reason why `static`, `explicit`, `virtual` and `constexpr=
` come first, and `noexcept` and the rest come last.</div><div><br></div><d=
iv>The keywords that come before function declarations define a fundamental=
 aspect of that function. `static` affects the function&#39;s linkage. `exp=
licit` affects when you can call it. `virtual` affects how that function in=
teracts with base/derived class functions with the same parameters. `conste=
xpr` affects when you can call the function.</div><div><br></div><div></div=
><div>By contrast, `noexcept` changes nothing about when you may call the f=
unction. Even from within a `noexcept` function, you can call non-`noexcept=
` functions. The `&amp;/&amp;&amp;/cv-qualifier` suffixes are effectively q=
ualifiers to the implicit-`this` parameter of the function. They do affect =
when you can call the function, but they affect it the way any function par=
ameter would, not in specialized ways like `static` and `constexpr`.</div><=
div><br></div><div>So it&#39;s not like which things are prefixes and which=
 are suffixes is entirely arbitrary. There is at least some logic to why so=
me come first and others come later.</div><div><br></div><div>So at the end=
 of the day, I do not see how your suggestion improves readability.<br></di=
v></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/209ffbde-2a77-460d-ab23-24a869d549d0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/209ffbde-2a77-460d-ab23-24a869d549d0=
%40isocpp.org</a>.<br />

------=_Part_2076_1283907027.1534280447054--

------=_Part_2075_1036184253.1534280447053--

.

------=_Part_2228_1413561784.1534290499453
Content-Type: multipart/alternative;
 boundary="----=_Part_2229_904886602.1534290499453"

------=_Part_2229_904886602.1534290499453
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 14, 2018 at 11:00:47 PM UTC+2, Nicol Bolas wrote:
>
>
> The keywords that come before function declarations define a fundamental
> aspect of that function. `static` affects the function's linkage.
> `explicit` affects when you can call it. `virtual` affects how that
> function interacts with base/derived class functions with the same
> parameters. `constexpr` affects when you can call the function.
>
>  I don't see how "constexpr" is a fundamental aspect of a function. It
literally changes nothing in the function's behavior.

--
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/1932ec70-01e5-4792-ac9c-8bab21433a75%40isocpp.org.

------=_Part_2229_904886602.1534290499453
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 14, 2018 at 11:00:47 PM UTC+2, Nicol Bo=
las 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"><di=
v><br></div><div>The keywords that come before function declarations define=
 a fundamental aspect of that function. `static` affects the function&#39;s=
 linkage. `explicit` affects when you can call it. `virtual` affects how th=
at function interacts with base/derived class functions with the same param=
eters. `constexpr` affects when you can call the function.</div><div><br></=
div></div></blockquote><div>=C2=A0I don&#39;t see how &quot;constexpr&quot;=
 is a fundamental aspect of a function. It literally changes nothing in the=
 function&#39;s behavior.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1932ec70-01e5-4792-ac9c-8bab21433a75%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1932ec70-01e5-4792-ac9c-8bab21433a75=
%40isocpp.org</a>.<br />

------=_Part_2229_904886602.1534290499453--

------=_Part_2228_1413561784.1534290499453--

.

------=_Part_2093_2059913443.1534292117648
Content-Type: multipart/alternative;
 boundary="----=_Part_2094_1427335037.1534292117648"

------=_Part_2094_1427335037.1534292117648
Content-Type: text/plain; charset="UTF-8"

On Tuesday, August 14, 2018 at 7:48:19 PM UTC-4, Dimitrij Mijoski wrote:
>
> On Tuesday, August 14, 2018 at 11:00:47 PM UTC+2, Nicol Bolas wrote:
>>
>>
>> The keywords that come before function declarations define a fundamental
>> aspect of that function. `static` affects the function's linkage.
>> `explicit` affects when you can call it. `virtual` affects how that
>> function interacts with base/derived class functions with the same
>> parameters. `constexpr` affects when you can call the function.
>>
>>  I don't see how "constexpr" is a fundamental aspect of a function. It
> literally changes nothing in the function's behavior.
>

You may have misunderstood what I was saying. A non-`constexpr` function
can't do this:

std::array<SomeType, func(20)> val;

`func` must be `constexpr` for this to be legal. I would consider the
ability for `func` to be used in this way to be "a fundamental aspect of a
function". Just like the ability of a constructor to not be used for
implicit conversion (`explicit`), or the ability of a function to be
overloaded (`virtual`), or the ability of a function to have internal
linkage/be bound to the class (`static`).

These are not aspects of "the function's behavior", and I never said they
were. These are aspects of how the function *is used*.

`noexcept` tells you something about how the function executes. `constexpr`
tells you when it is legal to call it.

--
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/7b381a4b-9d70-45f5-9b4d-3c23ad1aa078%40isocpp.org.

------=_Part_2094_1427335037.1534292117648
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, August 14, 2018 at 7:48:19 PM UTC-4, Dimitrij =
Mijoski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Tuesday, August 14, 2018 at 11:00:47 PM UTC+2, Nicol Bolas wrote:<block=
quote 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><br></div><div>The =
keywords that come before function declarations define a fundamental aspect=
 of that function. `static` affects the function&#39;s linkage. `explicit` =
affects when you can call it. `virtual` affects how that function interacts=
 with base/derived class functions with the same parameters. `constexpr` af=
fects when you can call the function.</div><div><br></div></div></blockquot=
e><div>=C2=A0I don&#39;t see how &quot;constexpr&quot; is a fundamental asp=
ect of a function. It literally changes nothing in the function&#39;s behav=
ior.<br></div></div></blockquote><div><br></div><div>You may have misunders=
tood what I was saying. A non-`constexpr` function can&#39;t do this:</div>=
<div><br></div><div><div style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; over=
flow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">arr=
ay</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">SomeType</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">20</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">)&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> val</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span></div></code></div></div><div><br></div><div>`fu=
nc` must be `constexpr` for this to be legal. I would consider the ability =
for `func` to be used in this way to be &quot;a fundamental aspect of a fun=
ction&quot;. Just like the ability of a constructor to not be used for impl=
icit conversion (`explicit`), or the ability of a function to be overloaded=
 (`virtual`), or the ability of a function to have internal linkage/be boun=
d to the class (`static`).</div><div><br></div><div>These are not aspects o=
f &quot;the function&#39;s behavior&quot;, and I never said they were. Thes=
e are aspects of how the function <i>is used</i>.</div><div><br></div><div>=
`noexcept` tells you something about how the function executes. `constexpr`=
 tells you when it is legal to call it.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7b381a4b-9d70-45f5-9b4d-3c23ad1aa078%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7b381a4b-9d70-45f5-9b4d-3c23ad1aa078=
%40isocpp.org</a>.<br />

------=_Part_2094_1427335037.1534292117648--

------=_Part_2093_2059913443.1534292117648--

.

------=_Part_2164_1378627200.1534316307165
Content-Type: multipart/alternative;
 boundary="----=_Part_2165_616224075.1534316307166"

------=_Part_2165_616224075.1534316307166
Content-Type: text/plain; charset="UTF-8"

On Wednesday, August 15, 2018 at 2:15:17 AM UTC+2, Nicol Bolas wrote:

> You may have misunderstood what I was saying. A non-`constexpr` function
> can't do this:
>
> std::array<SomeType, func(20)> val;
>
> `func` must be `constexpr` for this to be legal. I would consider the
> ability for `func` to be used in this way to be "a fundamental aspect of a
> function".
>

I wouldn't describe as fundamental the stuff that does not affect the
behavior of the function. No sir, I don't want to be that guy.

--
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/4a8626ad-7ae7-45fe-a758-e01eb5d50a1e%40isocpp.org.

------=_Part_2165_616224075.1534316307166
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, August 15, 2018 at 2:15:17 AM UTC+2, Nicol B=
olas wrote:<br><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>You may have misunderstood what I was saying. A non-`constexpr` func=
tion can&#39;t do this:</div><div><br></div><div><div style=3D"background-c=
olor:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bord=
er-width:1px"><code><div><span style=3D"color:#000">std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#000">array</span><span style=
=3D"color:#660">&lt;</span><span style=3D"color:#606">SomeType</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> func</span><span s=
tyle=3D"color:#660">(</span><span style=3D"color:#066">20</span><span style=
=3D"color:#660">)&gt;</span><span style=3D"color:#000"> val</span><span sty=
le=3D"color:#660">;</span></div></code></div></div><div><br></div><div>`fun=
c` must be `constexpr` for this to be legal. I would consider the ability f=
or `func` to be used in this way to be &quot;a fundamental aspect of a func=
tion&quot;.</div></div></blockquote><div><br></div><div>I wouldn&#39;t desc=
ribe as fundamental the stuff that does not affect the behavior of the func=
tion. No sir, I don&#39;t want to be that guy.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4a8626ad-7ae7-45fe-a758-e01eb5d50a1e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a8626ad-7ae7-45fe-a758-e01eb5d50a1e=
%40isocpp.org</a>.<br />

------=_Part_2165_616224075.1534316307166--

------=_Part_2164_1378627200.1534316307165--

.

------=_Part_2358_1859567201.1534344533160
Content-Type: multipart/alternative;
 boundary="----=_Part_2359_437896269.1534344533160"

------=_Part_2359_437896269.1534344533160
Content-Type: text/plain; charset="UTF-8"



On Wednesday, August 15, 2018 at 2:58:27 AM UTC-4, Dimitrij Mijoski wrote:
>
> On Wednesday, August 15, 2018 at 2:15:17 AM UTC+2, Nicol Bolas wrote:
>
>> You may have misunderstood what I was saying. A non-`constexpr` function
>> can't do this:
>>
>> std::array<SomeType, func(20)> val;
>>
>> `func` must be `constexpr` for this to be legal. I would consider the
>> ability for `func` to be used in this way to be "a fundamental aspect of a
>> function".
>>
>
> I wouldn't describe as fundamental the stuff that does not affect the
> behavior of the function. No sir, I don't want to be that guy.
>

Now you're just trying to argue semantics, so lets cut to the chase.

The keywords that come before the function declaration deal with how the
function may be used. The keywords and symbols that come after the function
parameters deal with how the function *behaves*. Whether you consider these
"fundamental aspects" or whatever, these are undeniably *different*.

As such, it is not unreasonable that syntax which affects function usage
appears in a different location from syntax which affects function behavior.

--
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/ac677c85-e98b-4431-a44d-97b5651b2d63%40isocpp.org.

------=_Part_2359_437896269.1534344533160
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, August 15, 2018 at 2:58:27 AM UTC-4,=
 Dimitrij Mijoski wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Wednesday, August 15, 2018 at 2:15:17 AM UTC+2, Nicol Bolas w=
rote:<br><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>You =
may have misunderstood what I was saying. A non-`constexpr` function can&#3=
9;t do this:</div><div><br></div><div><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x"><code><div><span style=3D"color:#000">std</span><span style=3D"color:#66=
0">::</span><span style=3D"color:#000">array</span><span style=3D"color:#66=
0">&lt;</span><span style=3D"color:#606">SomeType</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> func</span><span style=3D"color=
:#660">(</span><span style=3D"color:#066">20</span><span style=3D"color:#66=
0">)&gt;</span><span style=3D"color:#000"> val</span><span style=3D"color:#=
660">;</span></div></code></div></div><div><br></div><div>`func` must be `c=
onstexpr` for this to be legal. I would consider the ability for `func` to =
be used in this way to be &quot;a fundamental aspect of a function&quot;.</=
div></div></blockquote><div><br></div><div>I wouldn&#39;t describe as funda=
mental the stuff that does not affect the behavior of the function. No sir,=
 I don&#39;t want to be that guy.<br></div></div></blockquote><div><br></di=
v><div>Now you&#39;re just trying to argue semantics, so lets cut to the ch=
ase.<br></div><div><br></div><div>The keywords that come before the functio=
n declaration deal with how the function may be used. The keywords and symb=
ols that come after the function parameters deal with how the function <i>b=
ehaves</i>. Whether you consider these &quot;fundamental aspects&quot; or w=
hatever, these are undeniably <i>different</i>.</div><div><br></div><div>As=
 such, it is not unreasonable that syntax which affects function usage appe=
ars in a different location from syntax which affects function behavior.<br=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ac677c85-e98b-4431-a44d-97b5651b2d63%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ac677c85-e98b-4431-a44d-97b5651b2d63=
%40isocpp.org</a>.<br />

------=_Part_2359_437896269.1534344533160--

------=_Part_2358_1859567201.1534344533160--

.