--94eb2c08c3380c1996056158589c
Content-Type: text/plain; charset="UTF-8"

I don't think the stated opinion to the effect that [[fallthrough]] should
become mandatory is shared by everyone (to some, me included, the potential
removal of warnings is sufficient in itself), and I don't share your
reading of [[noreturn]] (there's nothing in [dcl.attr.noreturn] that
suggests this would be meant to make non-[[noreturn]]-non-returning
functions ill-formed).

However, the core point you are trying to make with attributes is
interesting; would you care making a paper out of it? I might make
interesting food for thought, should it be fleshed out with examples (in
addition to no_unique_address]]) where the "ignorable" characteristic of
attributes seems not to be respected.

Thanks!

2017-12-27 14:44 GMT-05:00 <mihailnajdenov@gmail.com>:

> Yet inline is a keyword and can be ignored and barely have "language
> semantic meaning". Granted, that ship has sailed long ago.
>
>
> In any case, you are right - [[no_unique_address]], on and off, creates
> two different programs, granted both well-formed, but different never the
> less.
>
> All other attributes so far fall into only two categories - communication
> with the user (more errors and warnings) and turning off synchronizations.
> In neither case the program is observably (as in static checks, not
> performance) different.
>
> I don't know how to feel about it. Never ever though about attributes as
> ignorable. Ever.
> Especially before standardization when people went to great lengths to add
> an attribute for every compiler and every platform precisely because their
> program depended on it.
> Sometimes vitally (like in "it will crash in minutes otherwise").
>
>
> --
> 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/40edf1b5-5c72-4682-
> 902e-1c0cea581e37%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37%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/CAKiZDp1uacYJk53zG%3DP4t2X98Hks9KpEnqaHXsv%3DV%2BByAu0B%3DQ%40mail.gmail.com.

--94eb2c08c3380c1996056158589c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I don&#39;t think the stated opinion to the effect th=
at [[fallthrough]] should become mandatory is shared by everyone (to some, =
me included, the potential removal of warnings is sufficient in itself), an=
d I don&#39;t share your reading of [[noreturn]] (there&#39;s nothing in [d=
cl.attr.noreturn] that suggests this would be meant to make non-[[noreturn]=
]-non-returning functions ill-formed).</div><div><br></div><div>However, th=
e core point you are trying to make with attributes is interesting; would y=
ou care making a paper out of it? I might make interesting food for thought=
, should it be fleshed out with examples (in addition to no_unique_address]=
]) where the &quot;ignorable&quot; characteristic of attributes seems not t=
o be respected.<br><br></div>Thanks!<br></div><div class=3D"gmail_extra"><b=
r><div class=3D"gmail_quote">2017-12-27 14:44 GMT-05:00  <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mihailnajdenov@gmail.com" target=3D"_blank">mihailnaj=
denov@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>Yet inline is a keyword and can be ignored and barely have &q=
uot;language semantic meaning&quot;. Granted, that ship has sailed long ago=
..=C2=A0</div><div><br></div><div><br></div><div>In any case, you are right =
-=C2=A0[[no_unique_address]], on and off, creates two different programs, g=
ranted both well-formed, but different never the less.</div><div><br></div>=
<div>All other attributes so far fall into only two categories - communicat=
ion with the user (more errors and warnings) and turning off synchronizatio=
ns. </div><div>In neither case the program is observably (as in static chec=
ks, not performance) different.=C2=A0</div><div><br></div><div>I don&#39;t =
know how to feel about it. Never ever though about attributes as ignorable.=
 Ever. </div><div>Especially before standardization when people went to gre=
at lengths to add an attribute for every compiler and every platform precis=
ely because their program depended on it.</div><div>Sometimes vitally (like=
 in &quot;it will crash in minutes otherwise&quot;).=C2=A0</div><div><br></=
div><div><br></div></div><span class=3D"">

<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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/40ed=
f1b5-5c72-4682-<wbr>902e-1c0cea581e37%40isocpp.org</a><wbr>.<br>
</blockquote></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/CAKiZDp1uacYJk53zG%3DP4t2X98Hks9KpEnq=
aHXsv%3DV%2BByAu0B%3DQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp1u=
acYJk53zG%3DP4t2X98Hks9KpEnqaHXsv%3DV%2BByAu0B%3DQ%40mail.gmail.com</a>.<br=
 />

--94eb2c08c3380c1996056158589c--

.

------=_Part_22260_999707701.1514410321836
Content-Type: multipart/alternative;
 boundary="----=_Part_22261_1487255385.1514410321836"

------=_Part_22261_1487255385.1514410321836
Content-Type: text/plain; charset="UTF-8"



On Wednesday, December 27, 2017 at 10:35:47 PM UTC+2, Patrice Roy wrote:
>
> I don't think the stated opinion to the effect that [[fallthrough]] should
> become mandatory is shared by everyone (to some, me included, the potential
> removal of warnings is sufficient in itself), and I don't share your
> reading of [[noreturn]] (there's nothing in [dcl.attr.noreturn] that
> suggests this would be meant to make non-[[noreturn]]-non-returning
> functions ill-formed).
>
> However, the core point you are trying to make with attributes is
> interesting; would you care making a paper out of it? I might make
> interesting food for thought, should it be fleshed out with examples (in
> addition to no_unique_address]]) where the "ignorable" characteristic of
> attributes seems not to be respected.
>
>
The author of the paper is clear, he respects the ignorable property.
However he concludes, only difference is the fact the ABI is changed, where
Nicol points out, it is more then that. In deed, a program coded with no_unique_address
could fail to compile or change behavior if the attribute is ignored.

--
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/d4cf9fd6-9464-4883-a7b1-89929f05ed23%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, December 27, 2017 at 10:35:47 PM UTC=
+2, Patrice Roy 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>I don&#39;t think the stated opinion to the effect that [[fal=
lthrough]] should become mandatory is shared by everyone (to some, me inclu=
ded, the potential removal of warnings is sufficient in itself), and I don&=
#39;t share your reading of [[noreturn]] (there&#39;s nothing in [dcl.attr.=
noreturn] that suggests this would be meant to make non-[[noreturn]]-non-re=
turning functions ill-formed).</div><div><br></div><div>However, the core p=
oint you are trying to make with attributes is interesting; would you care =
making a paper out of it? I might make interesting food for thought, should=
 it be fleshed out with examples (in addition to no_unique_address]]) where=
 the &quot;ignorable&quot; characteristic of attributes seems not to be res=
pected.<br><br></div></div></blockquote><div><br></div><div>The author of t=
he paper is clear, he respects the ignorable property. </div><div>However h=
e concludes, only difference is the fact the ABI is changed, where Nicol po=
ints out, it is more then that. In deed, a program coded with=C2=A0<span st=
yle=3D"display: inline !important; float: none; background-color: transpare=
nt; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helvetica&=
quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: normal=
; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; t=
ext-decoration: none; text-indent: 0px; text-transform: none; -webkit-text-=
stroke-width: 0px; white-space: normal; word-spacing: 0px;">no_unique_addre=
ss could fail to compile or change behavior if the attribute is ignored.</s=
pan></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/d4cf9fd6-9464-4883-a7b1-89929f05ed23%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d4cf9fd6-9464-4883-a7b1-89929f05ed23=
%40isocpp.org</a>.<br />

------=_Part_22261_1487255385.1514410321836--

------=_Part_22260_999707701.1514410321836--

.

------=_Part_22438_1689182659.1514410669913
Content-Type: multipart/alternative;
 boundary="----=_Part_22439_1713160479.1514410669913"

------=_Part_22439_1713160479.1514410669913
Content-Type: text/plain; charset="UTF-8"

On Wednesday, December 27, 2017 at 3:35:47 PM UTC-5, Patrice Roy wrote:
>
> I don't think the stated opinion to the effect that [[fallthrough]] should
> become mandatory is shared by everyone (to some, me included, the potential
> removal of warnings is sufficient in itself),
>

Put it this way; if you had a complete blank slate language, and for some
reason you decided this language desperately needed `switch/case`, and you
decided that fallthrough behavior was a useful feature for it... would you
make fall through the default, rather than having some actual syntax for it?

If the answer is "no", then the next question is how we get from where we
are (default fallthrough) to a place where we can reasonably change the
language to behave the way we would prefer. And the only way to take that
step is for the fallthrough syntax to be a real part of the language,
rather than something that is conceptually ignorable.

Now, maybe that's a step you don't want C++ to take; maybe you're fine with
the current state of having to turn on specific warnings/errors to get that
behavior for your codebase.

But if that's a step that C++ *ever* wants to take, we will* have to*
canonize [[fallthrough]]; we would have to make it real syntax. And it
seems silly to limit ourselves into never being able to take such a step,
simply because we made an arbitrary decision about how to express the
"fallthrough" behavior, not because of the actual *feasibility* of the
change (ie: checking out how much code will be broken and so forth).

and I don't share your reading of [[noreturn]] (there's nothing in
> [dcl.attr.noreturn] that suggests this would be meant to make
> non-[[noreturn]]-non-returning functions ill-formed).
>

This is something of a spin-off of the "Why is C++ still allowing UB when a
return statement is forgotten?" thread. But the basic idea is similar to
the above. With `unreachable`, we have a way to tell the compiler, "Yes, I
really mean for this code path to never, ever be taken".

Once that tool exists and is widely in use, it then becomes at least
feasible for compilers to give errors if static code paths don't return.
But the thing is, calling a `[[noreturn]]` function ought to be
conceptually identical to invoking `unreachable`; control flow* cannot*
return from that function, so that codepath cannot proceed forward. And
therefore, a code path that invokes a [[noreturn]] function ought to have
similar effects as `unreachable`: it's a code path that won't continue
forward.

Therefore, if we should ever decide to make static non-returning paths
error, we would have to canonize `[[noreturn]]`. We would have to add a
rule saying that code paths which don't return, throw, invoke `unreachable`,*
or* call a [[noreturn]] function are the ones that cause errors.

That no longer treats `[[noreturn]]` as ignorable syntax.

However, the core point you are trying to make with attributes is
> interesting; would you care making a paper out of it? I might make
> interesting food for thought, should it be fleshed out with examples (in
> addition to no_unique_address]]) where the "ignorable" characteristic of
> attributes seems not to be respected.
>
> Thanks!
>
> 2017-12-27 14:44 GMT-05:00 <mihailn...@gmail.com <javascript:>>:
>
>> Yet inline is a keyword and can be ignored and barely have "language
>> semantic meaning". Granted, that ship has sailed long ago.
>>
>>
>> In any case, you are right - [[no_unique_address]], on and off, creates
>> two different programs, granted both well-formed, but different never the
>> less.
>>
>> All other attributes so far fall into only two categories - communication
>> with the user (more errors and warnings) and turning off synchronizations.
>> In neither case the program is observably (as in static checks, not
>> performance) different.
>>
>> I don't know how to feel about it. Never ever though about attributes as
>> ignorable. Ever.
>> Especially before standardization when people went to great lengths to
>> add an attribute for every compiler and every platform precisely because
>> their program depended on it.
>> Sometimes vitally (like in "it will crash in minutes otherwise").
>>
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37%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/3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, December 27, 2017 at 3:35:47 PM UTC-5, Patri=
ce Roy wrote:<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>I don&#39;t think the stated opinion to the effect that [[fallthrough]=
] should become mandatory is shared by everyone (to some, me included, the =
potential removal of warnings is sufficient in itself),</div></div></blockq=
uote><div><br></div><div>Put it this way; if you had a complete blank slate=
 language, and for some reason you decided this language desperately needed=
 `switch/case`, and you decided that fallthrough behavior was a useful feat=
ure for it... would you make fall through the default, rather than having s=
ome actual syntax for it?</div><div><br></div><div>If the answer is &quot;n=
o&quot;, then the next question is how we get from where we are (default fa=
llthrough) to a place where we can reasonably change the language to behave=
 the way we would prefer. And the only way to take that step is for the fal=
lthrough syntax to be a real part of the language, rather than something th=
at is conceptually ignorable.</div><div><br></div><div>Now, maybe that&#39;=
s a step you don&#39;t want C++ to take; maybe you&#39;re fine with the cur=
rent state of having to turn on specific warnings/errors to get that behavi=
or for your codebase.</div><div><br></div><div>But if that&#39;s a step tha=
t C++ <i>ever</i> wants to take, we will<i> have to</i> canonize [[fallthro=
ugh]]; we would have to make it real syntax. And it seems silly to limit ou=
rselves into never being able to take such a step, simply because we made a=
n arbitrary decision about how to express the &quot;fallthrough&quot; behav=
ior, not because of the actual <i>feasibility</i> of the change (ie: checki=
ng out how much code will be broken and so forth).</div><div><br></div><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"><div><i></i>and I=
 don&#39;t share your reading of [[noreturn]] (there&#39;s nothing in [dcl.=
attr.noreturn] that suggests this would be meant to make non-[[noreturn]]-n=
on-returning functions ill-formed).</div></div></blockquote><div><br></div>=
<div>This is something of a spin-off of the &quot;Why is C++ still allowing=
 UB=C2=A0when a return statement is forgotten?&quot; thread. But the basic =
idea is similar to the above. With `unreachable`, we have a way to tell the=
 compiler, &quot;Yes, I really mean for this code path to never, ever be ta=
ken&quot;.</div><div><br></div><div>Once that tool exists and is widely in =
use, it then becomes at least feasible for compilers to give errors if stat=
ic code paths don&#39;t return. But the thing is, calling a `[[noreturn]]` =
function ought to be conceptually identical to invoking `unreachable`; cont=
rol flow<i> cannot</i> return from that function, so that codepath cannot p=
roceed forward. And therefore, a code path that invokes a [[noreturn]] func=
tion ought to have similar effects as `unreachable`: it&#39;s a code path t=
hat won&#39;t continue forward.</div><div><br></div><div>Therefore, if we s=
hould ever decide to make static non-returning paths error, we would have t=
o canonize `[[noreturn]]`. We would have to add a rule saying that code pat=
hs which don&#39;t return, throw, invoke `unreachable`,<i> or</i> call a [[=
noreturn]] function are the ones that cause errors.</div><div><br></div><di=
v>That no longer treats `[[noreturn]]` as ignorable syntax.<i></i></div><di=
v><br></div><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"><=
div>However, the core point you are trying to make with attributes is inter=
esting; would you care making a paper out of it? I might make interesting f=
ood for thought, should it be fleshed out with examples (in addition to no_=
unique_address]]) where the &quot;ignorable&quot; characteristic of attribu=
tes seems not to be respected.<br><br></div>Thanks!<br></div><div><br><div =
class=3D"gmail_quote">2017-12-27 14:44 GMT-05:00  <span dir=3D"ltr">&lt;<a =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;" href=3D"javascript:" target=
=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"UPvCBcT5CAAJ">mihailn=
....@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div>Yet inline is a keyword and can be ignored and barely have &quot=
;language semantic meaning&quot;. Granted, that ship has sailed long ago.=
=C2=A0</div><div><br></div><div><br></div><div>In any case, you are right -=
=C2=A0[[no_unique_address]], on and off, creates two different programs, gr=
anted both well-formed, but different never the less.</div><div><br></div><=
div>All other attributes so far fall into only two categories - communicati=
on with the user (more errors and warnings) and turning off synchronization=
s. </div><div>In neither case the program is observably (as in static check=
s, not performance) different.=C2=A0</div><div><br></div><div>I don&#39;t k=
now how to feel about it. Never ever though about attributes as ignorable. =
Ever. </div><div>Especially before standardization when people went to grea=
t lengths to add an attribute for every compiler and every platform precise=
ly because their program depended on it.</div><div>Sometimes vitally (like =
in &quot;it will crash in minutes otherwise&quot;).=C2=A0</div><div><br></d=
iv><div><br></div></div><span>

<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 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" o=
nclick=3D"this.href=3D&#39;javascript:&#39;;return true;" href=3D"javascrip=
t:" target=3D"_blank" rel=3D"nofollow" gdf-obfuscated-mailto=3D"UPvCBcT5CAA=
J">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;" href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" gdf-obf=
uscated-mailto=3D"UPvCBcT5CAAJ">std-pr...@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a onmousedown=3D"this.href=3D&#39=
;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72=
-4682-902e-1c0cea581e37%40isocpp.org?utm_medium\x3demail\x26utm_source\x3df=
ooter&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37=
%40isocpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;=
" href=3D"https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40ed=
f1b5-5c72-4682-902e-1c0cea581e37%40isocpp.org?utm_medium=3Demail&amp;utm_so=
urce=3Dfooter" target=3D"_blank" rel=3D"nofollow">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/40edf1b5-5c72-4682-<wbr>902e-=
1c0cea581e37%40isocpp.org</a><wbr>.<br>
</blockquote></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/3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf=
%40isocpp.org</a>.<br />

------=_Part_22439_1713160479.1514410669913--

------=_Part_22438_1689182659.1514410669913--

.

--001a113adaa463e7e105615a1405
Content-Type: text/plain; charset="UTF-8"

On 27 Dec 2017 21:37, "Nicol Bolas" <jmckesson@gmail.com> wrote:

If the answer is "no", then the next question is how we get from where we
are (default fallthrough) to a place where we can reasonably change the
language to behave the way we would prefer. And the only way to take that
step is for the fallthrough syntax to be a real part of the language,
rather than something that is conceptually ignorable.


For *a* fallthrough syntax. I wouldn't use "[[fallthrough]]" to continue to
the next case whilst using "break" to exit the switch. It's far too
inconsistent, and is not something anyone would cime up with that from a
"blank slate" POV. I'd just want "fallthrough". Or repurpose "continue"
(though that'd play hell with legacy code) as in Perl. But either way, I'd
move from attribute to keyword.


But if that's a step that C++ *ever* wants to take, we will* have to*
canonize [[fallthrough]]; we would have to make it real syntax.


But that isn't what an attribute is for. I guess what you're saying is that
we should reevaluate what attributes are for. The problem as I see it isn't
that we are heading towards attributes which affect the language, it's that
we are heading towards something that isn't an attribute.

In terms of backwards compatibility, this seems backwards to me. We want to
enforce [[fallthrough]] so that legacy code no longer works on new
compilers but new code works on old compilers? Why not just add a
fallthrough keyword that fails on old compilers but keep legacy code
working on new compilers? Surely that's the more conventional approach?
Especially if we are heading towards changing as radical as changing
something so fundamental as a switch.

I'm not in support of making the fallthrough explicit. I agree that if I
were to take C++ and be able to make changes to the fundamentals, I'd
change a lot (my first would be introducing an optional argument to break
and continue in nested loops to identify which loop to break/continue, as
in PHP). However, I'd be hesitant to change the behaviour of switch
statements from the rest of the C-based languages. It's a behaviour shared
by the C family (to my knowledge), and I have to admit that sharing such
fundamentals is useful, especially when you're often flickering between
different projects with different languages.

--
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/CAC%2B0CCPJcZ3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%40mail.gmail.com.

--001a113adaa463e7e105615a1405
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><div class=3D"gma=
il_quote">On 27 Dec 2017 21:37, &quot;Nicol Bolas&quot; &lt;<a href=3D"mail=
to:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"attri=
bution"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"quoted-text=
">If the answer is &quot;no&quot;, then the next question is how we get fro=
m where we are (default fallthrough) to a place where we can reasonably cha=
nge the language to behave the way we would prefer. And the only way to tak=
e that step is for the fallthrough syntax to be a real part of the language=
, rather than something that is conceptually ignorable.</div></div></blockq=
uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">For <i>a</i>=
 fallthrough syntax. I wouldn&#39;t use &quot;[[fallthrough]]&quot; to cont=
inue to the next case whilst using &quot;break&quot; to exit the switch. It=
&#39;s far too inconsistent, and is not something anyone would cime up with=
 that from a &quot;blank slate&quot; POV. I&#39;d just want &quot;fallthrou=
gh&quot;. Or repurpose &quot;continue&quot; (though that&#39;d play hell wi=
th legacy code) as in Perl. But either way, I&#39;d move from attribute to =
keyword.</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div=
 class=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote"><blockquote =
class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div></div><div>But if that&#39;s a step that=
 C++ <i>ever</i> wants to take, we will<i> have to</i> canonize [[fallthrou=
gh]]; we would have to make it real syntax.</div></div></blockquote></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">But that isn&#39;t what =
an attribute is for. I guess what you&#39;re saying is that we should reeva=
luate what attributes are for. The problem as I see it isn&#39;t that we ar=
e heading towards attributes which affect the language, it&#39;s that we ar=
e heading towards something that isn&#39;t an attribute.</div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">In terms of backwards compatibility, this =
seems backwards to me. We want to enforce [[fallthrough]] so that legacy co=
de no longer works on new compilers but new code works on old compilers? Wh=
y not just add a fallthrough keyword that fails on old compilers but keep l=
egacy code working on new compilers? Surely that&#39;s the more conventiona=
l approach? Especially if we are heading towards changing as radical as cha=
nging something so fundamental as a switch.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">I&#39;m not in support of making the fallthrough explic=
it. I agree that if I were to take C++ and be able to make changes to the f=
undamentals, I&#39;d change a lot (my first would be introducing an optiona=
l argument to break and continue in nested loops to identify which loop to =
break/continue, as in PHP). However, I&#39;d be hesitant to change the beha=
viour of switch statements from the rest of the C-based languages. It&#39;s=
 a behaviour shared by the C family (to my knowledge), and I have to admit =
that sharing such fundamentals is useful, especially when you&#39;re often =
flickering between different projects with different languages.</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/CAC%2B0CCPJcZ3XBjUbgvDh%2BcGX2zw1-d8E=
cJrP8zwZZdXmTBdfCg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJcZ=
3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%40mail.gmail.com</a>.<br />

--001a113adaa463e7e105615a1405--

.

--001a113f0024d1438a05615a3659
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I'd like to add reflection to the discussion.

In the context of reflection/metaclasses, there needs to be a way to filter
entities. Attributes would be a great fit for that.

Some people have suggested that we need a new "decorator" feature for that
use case. However, such feature would be very similar to attributes but
would require a new syntax.
The attribute syntax also offers a lot of great useful features (
namespaces, parameters ) that are currently underused, to say the least.

Of course, if people start generating code based on the presence/value of
some attribute, that confers semantic meaning to the attribute that can
therefor not be ignored
And, that's okay.

 So, I was considering proposing the following guidelines:


   - Compiler vendor attributes should be disregardable by the compiler.
   - Whether a standard attributes can be disregarded should be evaluated
   on a per-attribute basis ( for future attributes )
   - Attributes unknown to the compiler should be exposed through a
   reflection API ( I have yet to think about how such api would look like =
).
   - Whether standard attributes should be exposed through the reflection
   api should be decided on a per attributes basis.
   - Contracts should not be exposed through the reflection API.
   - All non-standard attributes ( that is, attributes added for reflection
   purposes and those offered by vendors) should have a namespace qualifier=
..
   That should be the case already.




Le mer. 27 d=C3=A9c. 2017 =C3=A0 23:40, Jake Arkinstall <jake.arkinstall@gm=
ail.com> a
=C3=A9crit :

> On 27 Dec 2017 21:37, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> If the answer is "no", then the next question is how we get from where we
> are (default fallthrough) to a place where we can reasonably change the
> language to behave the way we would prefer. And the only way to take that
> step is for the fallthrough syntax to be a real part of the language,
> rather than something that is conceptually ignorable.
>
>
> For *a* fallthrough syntax. I wouldn't use "[[fallthrough]]" to continue
> to the next case whilst using "break" to exit the switch. It's far too
> inconsistent, and is not something anyone would cime up with that from a
> "blank slate" POV. I'd just want "fallthrough". Or repurpose "continue"
> (though that'd play hell with legacy code) as in Perl. But either way, I'=
d
> move from attribute to keyword.
>
>
> But if that's a step that C++ *ever* wants to take, we will* have to*
> canonize [[fallthrough]]; we would have to make it real syntax.
>
>
> But that isn't what an attribute is for. I guess what you're saying is
> that we should reevaluate what attributes are for. The problem as I see i=
t
> isn't that we are heading towards attributes which affect the language,
> it's that we are heading towards something that isn't an attribute.
>
> In terms of backwards compatibility, this seems backwards to me. We want
> to enforce [[fallthrough]] so that legacy code no longer works on new
> compilers but new code works on old compilers? Why not just add a
> fallthrough keyword that fails on old compilers but keep legacy code
> working on new compilers? Surely that's the more conventional approach?
> Especially if we are heading towards changing as radical as changing
> something so fundamental as a switch.
>
> I'm not in support of making the fallthrough explicit. I agree that if I
> were to take C++ and be able to make changes to the fundamentals, I'd
> change a lot (my first would be introducing an optional argument to break
> and continue in nested loops to identify which loop to break/continue, as
> in PHP). However, I'd be hesitant to change the behaviour of switch
> statements from the rest of the C-based languages. It's a behaviour share=
d
> by the C family (to my knowledge), and I have to admit that sharing such
> fundamentals is useful, especially when you're often flickering between
> different projects with different languages.
>
> --
> 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/CAC%2B0CCPJc=
Z3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPJ=
cZ3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%40mail.gmail.com?utm_medium=3D=
email&utm_source=3Dfooter>
> .
>

--=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/CA%2BOm%2BSj%3DzYZKA5WH_uShcTBBWD87sX_Es4a8qns96=
iqME8TmFA%40mail.gmail.com.

--001a113f0024d1438a05615a3659
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;d like to add reflection to the discussion.<div><br>=
</div><div><div style=3D""><div style=3D""><font color=3D"#212121">In the c=
ontext of reflection/metaclasses, there needs to be a way to filter entitie=
s. Attributes would be a great fit for that.</font></div><div style=3D""><f=
ont color=3D"#212121"><br></font></div><div style=3D""><font color=3D"#2121=
21">Some people have suggested that we need a new &quot;decorator&quot; fea=
ture for that use case. However, such feature would be very similar to attr=
ibutes but would require a new syntax.</font></div><div style=3D""><font co=
lor=3D"#212121">The attribute syntax also offers a lot of great useful feat=
ures ( namespaces, parameters ) that are currently underused, to say the le=
ast.</font></div><div style=3D""><font color=3D"#212121"><br></font></div><=
div style=3D"">Of course, if people start generating code based on the pres=
ence/value of some attribute, that confers semantic meaning to the attribut=
e that can therefor not be ignored<font color=3D"#212121"><br></font></div>=
<div style=3D"">And, that&#39;s okay.</div><div style=3D""><br></div><div s=
tyle=3D""><font color=3D"#212121">=C2=A0So, I was considering proposing the=
 following guidelines:</font></div><div style=3D""><font color=3D"#212121">=
<br></font></div><div style=3D""><ul><li>Compiler vendor attributes should =
be disregardable by the compiler.=C2=A0</li><li>Whether a standard attribut=
es can be disregarded should be evaluated on a per-attribute basis ( for fu=
ture attributes )</li><li>Attributes unknown to the compiler should be expo=
sed through a reflection API ( I have yet to think about how such api would=
 look like ).</li><li>Whether standard attributes should be exposed through=
 the reflection api should be decided on a per attributes basis.</li><li>Co=
ntracts should not be exposed through the reflection API.</li><li>All non-s=
tandard attributes ( that is, attributes added for reflection purposes and =
those offered by vendors) should have a namespace qualifier. That should be=
 the case already.</li></ul></div></div><div><br></div><div><br></div></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr">Le=C2=A0mer. 27 d=C3=A9c. =
2017 =C3=A0=C2=A023:40, Jake Arkinstall &lt;<a href=3D"mailto:jake.arkinsta=
ll@gmail.com" target=3D"_blank">jake.arkinstall@gmail.com</a>&gt; a =C3=A9c=
rit=C2=A0:<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"auto"><div c=
lass=3D"gmail_extra" dir=3D"auto"><div class=3D"gmail_quote">On 27 Dec 2017=
 21:37, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckesson@gmail.com" =
target=3D"_blank">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"attribution=
"><blockquote class=3D"m_-6358915301292842689m_-8262358137349249951quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div class=3D"m_-6358915301292842689m_-8262358137349249951quot=
ed-text">If the answer is &quot;no&quot;, then the next question is how we =
get from where we are (default fallthrough) to a place where we can reasona=
bly change the language to behave the way we would prefer. And the only way=
 to take that step is for the fallthrough syntax to be a real part of the l=
anguage, rather than something that is conceptually ignorable.</div></div><=
/blockquote></div></div><div dir=3D"auto"><br></div></div><div dir=3D"auto"=
><div dir=3D"auto">For <i>a</i> fallthrough syntax. I wouldn&#39;t use &quo=
t;[[fallthrough]]&quot; to continue to the next case whilst using &quot;bre=
ak&quot; to exit the switch. It&#39;s far too inconsistent, and is not some=
thing anyone would cime up with that from a &quot;blank slate&quot; POV. I&=
#39;d just want &quot;fallthrough&quot;. Or repurpose &quot;continue&quot; =
(though that&#39;d play hell with legacy code) as in Perl. But either way, =
I&#39;d move from attribute to keyword.</div></div><div dir=3D"auto"><div d=
ir=3D"auto">=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div class=3D"gmail_extr=
a" dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"m_-63589153=
01292842689m_-8262358137349249951quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>But i=
f that&#39;s a step that C++ <i>ever</i> wants to take, we will<i> have to<=
/i> canonize [[fallthrough]]; we would have to make it real syntax.</div></=
div></blockquote></div></div><div dir=3D"auto"><br></div></div><div dir=3D"=
auto"><div dir=3D"auto">But that isn&#39;t what an attribute is for. I gues=
s what you&#39;re saying is that we should reevaluate what attributes are f=
or. The problem as I see it isn&#39;t that we are heading towards attribute=
s which affect the language, it&#39;s that we are heading towards something=
 that isn&#39;t an attribute.</div><div dir=3D"auto"><br></div><div dir=3D"=
auto">In terms of backwards compatibility, this seems backwards to me. We w=
ant to enforce [[fallthrough]] so that legacy code no longer works on new c=
ompilers but new code works on old compilers? Why not just add a fallthroug=
h keyword that fails on old compilers but keep legacy code working on new c=
ompilers? Surely that&#39;s the more conventional approach? Especially if w=
e are heading towards changing as radical as changing something so fundamen=
tal as a switch.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#39;m=
 not in support of making the fallthrough explicit. I agree that if I were =
to take C++ and be able to make changes to the fundamentals, I&#39;d change=
 a lot (my first would be introducing an optional argument to break and con=
tinue in nested loops to identify which loop to break/continue, as in PHP).=
 However, I&#39;d be hesitant to change the behaviour of switch statements =
from the rest of the C-based languages. It&#39;s a behaviour shared by the =
C family (to my knowledge), and I have to admit that sharing such fundament=
als is useful, especially when you&#39;re often flickering between differen=
t projects with different languages.</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" 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/CAC%2B0CCPJcZ3XBjUbgvDh%2BcGX2zw1-d8E=
cJrP8zwZZdXmTBdfCg%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Dfoo=
ter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/CAC%2B0CCPJcZ3XBjUbgvDh%2BcGX2zw1-d8EcJrP8zwZZdXmTBdfCg%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&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/CA%2BOm%2BSj%3DzYZKA5WH_uShcTBBWD87sX=
_Es4a8qns96iqME8TmFA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2BOm%2BS=
j%3DzYZKA5WH_uShcTBBWD87sX_Es4a8qns96iqME8TmFA%40mail.gmail.com</a>.<br />

--001a113f0024d1438a05615a3659--

.

--001a114d7788286d8305615b0069
Content-Type: text/plain; charset="UTF-8"

Yes; I was just pointing out that a paper (with different examples; those
in the original post are not convincing, at least not to me) would be
appreciated. Regardless of our differences with respect to the examples
pointed out, I think a more thorough study of the core issues would be of
value.

2017-12-27 16:32 GMT-05:00 <mihailnajdenov@gmail.com>:

>
>
> On Wednesday, December 27, 2017 at 10:35:47 PM UTC+2, Patrice Roy wrote:
>>
>> I don't think the stated opinion to the effect that [[fallthrough]]
>> should become mandatory is shared by everyone (to some, me included, the
>> potential removal of warnings is sufficient in itself), and I don't share
>> your reading of [[noreturn]] (there's nothing in [dcl.attr.noreturn] that
>> suggests this would be meant to make non-[[noreturn]]-non-returning
>> functions ill-formed).
>>
>> However, the core point you are trying to make with attributes is
>> interesting; would you care making a paper out of it? I might make
>> interesting food for thought, should it be fleshed out with examples (in
>> addition to no_unique_address]]) where the "ignorable" characteristic of
>> attributes seems not to be respected.
>>
>>
> The author of the paper is clear, he respects the ignorable property.
> However he concludes, only difference is the fact the ABI is changed,
> where Nicol points out, it is more then that. In deed, a program coded with no_unique_address
> could fail to compile or change behavior if the attribute is ignored.
>
> --
> 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/d4cf9fd6-9464-4883-
> a7b1-89929f05ed23%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d4cf9fd6-9464-4883-a7b1-89929f05ed23%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/CAKiZDp2OVg48A0j_EFwHbLXB%3DsyAxDapRufkma3SDQMDfscg_Q%40mail.gmail.com.

--001a114d7788286d8305615b0069
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes; I was just pointing out that a paper (with different =
examples; those in the original post are not convincing, at least not to me=
) would be appreciated. Regardless of our differences with respect to the e=
xamples pointed out, I think a more thorough study of the core issues would=
 be of value.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">2017-12-27 16:32 GMT-05:00  <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
ihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@gmail.com</a>&gt;=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
"><br><br>On Wednesday, December 27, 2017 at 10:35:47 PM UTC+2, Patrice Roy=
 wrote:<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>I don&=
#39;t think the stated opinion to the effect that [[fallthrough]] should be=
come mandatory is shared by everyone (to some, me included, the potential r=
emoval of warnings is sufficient in itself), and I don&#39;t share your rea=
ding of [[noreturn]] (there&#39;s nothing in [dcl.attr.noreturn] that sugge=
sts this would be meant to make non-[[noreturn]]-non-returning functions il=
l-formed).</div><div><br></div><div>However, the core point you are trying =
to make with attributes is interesting; would you care making a paper out o=
f it? I might make interesting food for thought, should it be fleshed out w=
ith examples (in addition to no_unique_address]]) where the &quot;ignorable=
&quot; characteristic of attributes seems not to be respected.<br><br></div=
></div></blockquote><div><br></div></span><div>The author of the paper is c=
lear, he respects the ignorable property. </div><div>However he concludes, =
only difference is the fact the ABI is changed, where Nicol points out, it =
is more then that. In deed, a program coded with=C2=A0<span style=3D"displa=
y:inline!important;float:none;background-color:transparent;color:rgb(34,34,=
34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-siz=
e:13px;font-style:normal;font-variant:normal;font-weight:400;letter-spacing=
:normal;text-align:left;text-decoration:none;text-indent:0px;text-transform=
:none;white-space:normal;word-spacing:0px">no_unique_address could fail to =
compile or change behavior if the attribute is ignored.</span></div></div><=
span class=3D"">

<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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d4cf9fd6-9464-4883-a7b1-89929f05ed23%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/d4cf=
9fd6-9464-4883-<wbr>a7b1-89929f05ed23%40isocpp.org</a><wbr>.<br>
</blockquote></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/CAKiZDp2OVg48A0j_EFwHbLXB%3DsyAxDapRu=
fkma3SDQMDfscg_Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp2OVg48A0=
j_EFwHbLXB%3DsyAxDapRufkma3SDQMDfscg_Q%40mail.gmail.com</a>.<br />

--001a114d7788286d8305615b0069--

.

--f4030435ae78b71ad505615b0547
Content-Type: text/plain; charset="UTF-8"

Hi Nicol.

I'll let others discuss a potential new language. I don't agree with you on
surface issues, but the core interests me, so I'll repeat my encouragement
for a paper that studies it. I think it has value.

Thanks again!

2017-12-27 16:37 GMT-05:00 Nicol Bolas <jmckesson@gmail.com>:

> On Wednesday, December 27, 2017 at 3:35:47 PM UTC-5, Patrice Roy wrote:
>>
>> I don't think the stated opinion to the effect that [[fallthrough]]
>> should become mandatory is shared by everyone (to some, me included, the
>> potential removal of warnings is sufficient in itself),
>>
>
> Put it this way; if you had a complete blank slate language, and for some
> reason you decided this language desperately needed `switch/case`, and you
> decided that fallthrough behavior was a useful feature for it... would you
> make fall through the default, rather than having some actual syntax for it?
>
> If the answer is "no", then the next question is how we get from where we
> are (default fallthrough) to a place where we can reasonably change the
> language to behave the way we would prefer. And the only way to take that
> step is for the fallthrough syntax to be a real part of the language,
> rather than something that is conceptually ignorable.
>
> Now, maybe that's a step you don't want C++ to take; maybe you're fine
> with the current state of having to turn on specific warnings/errors to get
> that behavior for your codebase.
>
> But if that's a step that C++ *ever* wants to take, we will* have to*
> canonize [[fallthrough]]; we would have to make it real syntax. And it
> seems silly to limit ourselves into never being able to take such a step,
> simply because we made an arbitrary decision about how to express the
> "fallthrough" behavior, not because of the actual *feasibility* of the
> change (ie: checking out how much code will be broken and so forth).
>
> and I don't share your reading of [[noreturn]] (there's nothing in
>> [dcl.attr.noreturn] that suggests this would be meant to make
>> non-[[noreturn]]-non-returning functions ill-formed).
>>
>
> This is something of a spin-off of the "Why is C++ still allowing UB when
> a return statement is forgotten?" thread. But the basic idea is similar to
> the above. With `unreachable`, we have a way to tell the compiler, "Yes, I
> really mean for this code path to never, ever be taken".
>
> Once that tool exists and is widely in use, it then becomes at least
> feasible for compilers to give errors if static code paths don't return.
> But the thing is, calling a `[[noreturn]]` function ought to be
> conceptually identical to invoking `unreachable`; control flow* cannot*
> return from that function, so that codepath cannot proceed forward. And
> therefore, a code path that invokes a [[noreturn]] function ought to have
> similar effects as `unreachable`: it's a code path that won't continue
> forward.
>
> Therefore, if we should ever decide to make static non-returning paths
> error, we would have to canonize `[[noreturn]]`. We would have to add a
> rule saying that code paths which don't return, throw, invoke `unreachable`,*
> or* call a [[noreturn]] function are the ones that cause errors.
>
> That no longer treats `[[noreturn]]` as ignorable syntax.
>
> However, the core point you are trying to make with attributes is
>> interesting; would you care making a paper out of it? I might make
>> interesting food for thought, should it be fleshed out with examples (in
>> addition to no_unique_address]]) where the "ignorable" characteristic of
>> attributes seems not to be respected.
>>
>> Thanks!
>>
>> 2017-12-27 14:44 GMT-05:00 <mihailn...@gmail.com>:
>>
>>> Yet inline is a keyword and can be ignored and barely have "language
>>> semantic meaning". Granted, that ship has sailed long ago.
>>>
>>>
>>> In any case, you are right - [[no_unique_address]], on and off, creates
>>> two different programs, granted both well-formed, but different never the
>>> less.
>>>
>>> All other attributes so far fall into only two categories -
>>> communication with the user (more errors and warnings) and turning off
>>> synchronizations.
>>> In neither case the program is observably (as in static checks, not
>>> performance) different.
>>>
>>> I don't know how to feel about it. Never ever though about attributes as
>>> ignorable. Ever.
>>> Especially before standardization when people went to great lengths to
>>> add an attribute for every compiler and every platform precisely because
>>> their program depended on it.
>>> Sometimes vitally (like in "it will crash in minutes otherwise").
>>>
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit https://groups.google.com/a/is
>>> ocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-
>>> 1c0cea581e37%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37%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/3c34aa3e-bf47-4d4f-
> be71-522c7cc0a9bf%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf%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/CAKiZDp01ysJhDsfKp0Wi2SAS7DAs_%3DFFe3mdeO%2BNu1rg0kc8rA%40mail.gmail.com.

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

<div dir=3D"ltr"><div><div>Hi Nicol.<br><br></div>I&#39;ll let others discu=
ss a potential new language. I don&#39;t agree with you on surface issues, =
but the core interests me, so I&#39;ll repeat my encouragement for a paper =
that studies it. I think it has value.<br><br></div>Thanks again!<br></div>=
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-12-27 16:37 =
GMT-05:00 Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gma=
il.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span>:<br><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"><span class=3D"">On Wednesday, Decemb=
er 27, 2017 at 3:35:47 PM UTC-5, Patrice Roy wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div>I don&#39;t think the stated opinion =
to the effect that [[fallthrough]] should become mandatory is shared by eve=
ryone (to some, me included, the potential removal of warnings is sufficien=
t in itself),</div></div></blockquote><div><br></div></span><div>Put it thi=
s way; if you had a complete blank slate language, and for some reason you =
decided this language desperately needed `switch/case`, and you decided tha=
t fallthrough behavior was a useful feature for it... would you make fall t=
hrough the default, rather than having some actual syntax for it?</div><div=
><br></div><div>If the answer is &quot;no&quot;, then the next question is =
how we get from where we are (default fallthrough) to a place where we can =
reasonably change the language to behave the way we would prefer. And the o=
nly way to take that step is for the fallthrough syntax to be a real part o=
f the language, rather than something that is conceptually ignorable.</div>=
<div><br></div><div>Now, maybe that&#39;s a step you don&#39;t want C++ to =
take; maybe you&#39;re fine with the current state of having to turn on spe=
cific warnings/errors to get that behavior for your codebase.</div><div><br=
></div><div>But if that&#39;s a step that C++ <i>ever</i> wants to take, we=
 will<i> have to</i> canonize [[fallthrough]]; we would have to make it rea=
l syntax. And it seems silly to limit ourselves into never being able to ta=
ke such a step, simply because we made an arbitrary decision about how to e=
xpress the &quot;fallthrough&quot; behavior, not because of the actual <i>f=
easibility</i> of the change (ie: checking out how much code will be broken=
 and so forth).</div><span class=3D""><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><i></i>and I don&#39;t share your r=
eading of [[noreturn]] (there&#39;s nothing in [dcl.attr.noreturn] that sug=
gests this would be meant to make non-[[noreturn]]-non-returning functions =
ill-formed).</div></div></blockquote><div><br></div></span><div>This is som=
ething of a spin-off of the &quot;Why is C++ still allowing UB=C2=A0when a =
return statement is forgotten?&quot; thread. But the basic idea is similar =
to the above. With `unreachable`, we have a way to tell the compiler, &quot=
;Yes, I really mean for this code path to never, ever be taken&quot;.</div>=
<div><br></div><div>Once that tool exists and is widely in use, it then bec=
omes at least feasible for compilers to give errors if static code paths do=
n&#39;t return. But the thing is, calling a `[[noreturn]]` function ought t=
o be conceptually identical to invoking `unreachable`; control flow<i> cann=
ot</i> return from that function, so that codepath cannot proceed forward. =
And therefore, a code path that invokes a [[noreturn]] function ought to ha=
ve similar effects as `unreachable`: it&#39;s a code path that won&#39;t co=
ntinue forward.</div><div><br></div><div>Therefore, if we should ever decid=
e to make static non-returning paths error, we would have to canonize `[[no=
return]]`. We would have to add a rule saying that code paths which don&#39=
;t return, throw, invoke `unreachable`,<i> or</i> call a [[noreturn]] funct=
ion are the ones that cause errors.</div><div><br></div><div>That no longer=
 treats `[[noreturn]]` as ignorable syntax.<i></i></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><div>=
However, the core point you are trying to make with attributes is interesti=
ng; would you care making a paper out of it? I might make interesting food =
for thought, should it be fleshed out with examples (in addition to no_uniq=
ue_address]]) where the &quot;ignorable&quot; characteristic of attributes =
seems not to be respected.<br><br></div>Thanks!<br></div></span><div><br><d=
iv class=3D"gmail_quote"><span class=3D"">2017-12-27 14:44 GMT-05:00  <span=
 dir=3D"ltr">&lt;<a rel=3D"nofollow">mihailn...@gmail.com</a>&gt;</span>:<b=
r></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><=
div>Yet inline is a keyword and can be ignored and barely have &quot;langua=
ge semantic meaning&quot;. Granted, that ship has sailed long ago.=C2=A0</d=
iv><div><br></div><div><br></div><div>In any case, you are right -=C2=A0[[n=
o_unique_address]], on and off, creates two different programs, granted bot=
h well-formed, but different never the less.</div><div><br></div><div>All o=
ther attributes so far fall into only two categories - communication with t=
he user (more errors and warnings) and turning off synchronizations. </div>=
<div>In neither case the program is observably (as in static checks, not pe=
rformance) different.=C2=A0</div><div><br></div><div>I don&#39;t know how t=
o feel about it. Never ever though about attributes as ignorable. Ever. </d=
iv><div>Especially before standardization when people went to great lengths=
 to add an attribute for every compiler and every platform precisely becaus=
e their program depended on it.</div><div>Sometimes vitally (like in &quot;=
it will crash in minutes otherwise&quot;).=C2=A0</div><div><br></div><div><=
br></div></div></span><span><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br></span><span class=3D"">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/is<wbr>ocpp.org/d/msgid/std-pr=
oposals<wbr>/40edf1b5-5c72-4682-902e-<wbr>1c0cea581e37%40isocpp.org</a>.<br=
>
</span></blockquote></div><br></div>
</blockquote></div><span class=3D"">

<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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3c34aa3e-bf47-4d4f-be71-522c7cc0a9bf%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/3c34=
aa3e-bf47-4d4f-<wbr>be71-522c7cc0a9bf%40isocpp.org</a><wbr>.<br>
</blockquote></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/CAKiZDp01ysJhDsfKp0Wi2SAS7DAs_%3DFFe3=
mdeO%2BNu1rg0kc8rA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAKiZDp01ysJh=
DsfKp0Wi2SAS7DAs_%3DFFe3mdeO%2BNu1rg0kc8rA%40mail.gmail.com</a>.<br />

--f4030435ae78b71ad505615b0547--

.

On quinta-feira, 28 de dezembro de 2017 06:35:52 -02 mihailnajdenov@gmail.com
wrote:
> On Thursday, December 28, 2017 at 10:07:31 AM UTC+2, Victor Dyachenko wrote:
> > On Wednesday, December 27, 2017 at 10:44:13 PM UTC+3, mihailn...@gmail.com
> >
> > wrote:
> >> Yet inline is a keyword and can be ignored and barely have "language
> >> semantic meaning". Granted, that ship has sailed long ago.
> >
> > inline can't be ignored! It changes linkage of the fuction.
>
> It can not be ignored only in the context of multiple definitions. In the
> context of the actual inlining it can be ignored.
> Also, I don't think inline changes linkage - an inline function still has
> external linkage.

An inlined inline function has no external linkage, since it doesn't *exist*.

A non-inlined inline function has vauge linkage.

An non-inline function does have its normal linkage, whether it was inlined or
not.

In other words, the inline keyword does not control inlining. It controls the
presence of the out-of-line copy.


--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/8607542.V6lOK4bWWd%40tjmaciei-mobl1.

.

------=_Part_30392_714895748.1514651522290
Content-Type: multipart/alternative;
 boundary="----=_Part_30393_1751205955.1514651522290"

------=_Part_30393_1751205955.1514651522290
Content-Type: text/plain; charset="UTF-8"

On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Corentin wrote:
>
> I'd like to add reflection to the discussion.
>

> In the context of reflection/metaclasses, there needs to be a way to
> filter entities. Attributes would be a great fit for that.
>
> Some people have suggested that we need a new "decorator" feature for that
> use case. However, such feature would be very similar to attributes but
> would require a new syntax.
> The attribute syntax also offers a lot of great useful features (
> namespaces, parameters ) that are currently underused, to say the least.
>
> Of course, if people start generating code based on the presence/value of
> some attribute, that confers semantic meaning to the attribute that can
> therefor not be ignored
> And, that's okay.
>

That's a really good point. If we can reflect over attributes, then the
ability of attributes to be ignored goes away entirely. Or at least, is
based on what code someone uses. Even P0840's idea of saying that "a
program that works with the use of the attribute shall still behave as a
program without that attribute" fails, since reflection and code generation
based on that will change.

So it seems that this makes the current direction of attributes even less
tenable.

 So, I was considering proposing the following guidelines:
>
>
>    - Compiler vendor attributes should be disregardable by the compiler.
>    - Whether a standard attributes can be disregarded should be evaluated
>    on a per-attribute basis ( for future attributes )
>    - Attributes unknown to the compiler should be exposed through a
>    reflection API ( I have yet to think about how such api would look like ).
>
> If attributes are exposed to reflection, then *all* attributes should be
exposed. There's no reason I shouldn't be able to ask if a function is
`noreturn` or whatever.

>
>    - Whether standard attributes should be exposed through the reflection
>    api should be decided on a per attributes basis.
>    - Contracts should not be exposed through the reflection API.
>    - All non-standard attributes ( that is, attributes added for
>    reflection purposes and those offered by vendors) should have a namespace
>    qualifier. That should be the case already.
>
>
>

--
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/99dbedb0-ba68-4245-a809-a7e8d9f0c501%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Coren=
tin 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">I&#=
39;d like to add reflection to the discussion.=C2=A0</div></blockquote><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"><div><br></div><d=
iv><div><div><font color=3D"#212121">In the context of reflection/metaclass=
es, there needs to be a way to filter entities. Attributes would be a great=
 fit for that.</font></div><div><font color=3D"#212121"><br></font></div><d=
iv><font color=3D"#212121">Some people have suggested that we need a new &q=
uot;decorator&quot; feature for that use case. However, such feature would =
be very similar to attributes but would require a new syntax.</font></div><=
div><font color=3D"#212121">The attribute syntax also offers a lot of great=
 useful features ( namespaces, parameters ) that are currently underused, t=
o say the least.</font></div><div><font color=3D"#212121"><br></font></div>=
<div>Of course, if people start generating code based on the presence/value=
 of some attribute, that confers semantic meaning to the attribute that can=
 therefor not be ignored<font color=3D"#212121"><br></font></div><div>And, =
that&#39;s okay.</div></div></div></div></blockquote><div><br></div><div>Th=
at&#39;s a really good point. If we can reflect over attributes, then the a=
bility of attributes to be ignored goes away entirely. Or at least, is base=
d on what code someone uses. Even P0840&#39;s idea of saying that &quot;a p=
rogram that works with the use of the attribute shall still behave as a pro=
gram without that attribute&quot; fails, since reflection and code generati=
on based on that will change.</div><div><br></div><div>So it seems that thi=
s makes the current direction of attributes even less tenable.</div><div><b=
r></div><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>=
<div><div><font color=3D"#212121">=C2=A0So, I was considering proposing the=
 following guidelines:</font></div><div><font color=3D"#212121"><br></font>=
</div><div><ul><li>Compiler vendor attributes should be disregardable by th=
e compiler.=C2=A0</li><li>Whether a standard attributes can be disregarded =
should be evaluated on a per-attribute basis ( for future attributes )</li>=
<li>Attributes unknown to the compiler should be exposed through a reflecti=
on API ( I have yet to think about how such api would look like ).</li></ul=
></div></div></div></div></blockquote><div>If attributes are exposed to ref=
lection, then <i>all</i> attributes should be exposed. There&#39;s no reaso=
n I shouldn&#39;t be able to ask if a function is `noreturn` or whatever.</=
div><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><div=
><div><ul><li>Whether standard attributes should be exposed through the ref=
lection api should be decided on a per attributes basis.</li><li>Contracts =
should not be exposed through the reflection API.</li><li>All non-standard =
attributes ( that is, attributes added for reflection purposes and those of=
fered by vendors) should have a namespace qualifier. That should be the cas=
e already.</li></ul></div></div><div><br></div></div><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
</blockquote></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&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/99dbedb0-ba68-4245-a809-a7e8d9f0c501%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99dbedb0-ba68-4245-a809-a7e8d9f0c501=
%40isocpp.org</a>.<br />

------=_Part_30393_1751205955.1514651522290--

------=_Part_30392_714895748.1514651522290--

.

------=_Part_31266_2016374889.1514657179558
Content-Type: multipart/alternative;
 boundary="----=_Part_31267_766688469.1514657179558"

------=_Part_31267_766688469.1514657179558
Content-Type: text/plain; charset="UTF-8"



On Saturday, December 30, 2017 at 5:32:02 PM UTC+1, Nicol Bolas wrote:
>
> On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Corentin wrote:
>>
>> I'd like to add reflection to the discussion.
>>
>
>> In the context of reflection/metaclasses, there needs to be a way to
>> filter entities. Attributes would be a great fit for that.
>>
>> Some people have suggested that we need a new "decorator" feature for
>> that use case. However, such feature would be very similar to attributes
>> but would require a new syntax.
>> The attribute syntax also offers a lot of great useful features (
>> namespaces, parameters ) that are currently underused, to say the least.
>>
>> Of course, if people start generating code based on the presence/value of
>> some attribute, that confers semantic meaning to the attribute that can
>> therefor not be ignored
>> And, that's okay.
>>
>
> That's a really good point. If we can reflect over attributes, then the
> ability of attributes to be ignored goes away entirely. Or at least, is
> based on what code someone uses. Even P0840's idea of saying that "a
> program that works with the use of the attribute shall still behave as a
> program without that attribute" fails, since reflection and code generation
> based on that will change.
>
> So it seems that this makes the current direction of attributes even less
> tenable.
>
>
IMHO "ignored" in sens that they have no meaning for compiler not that they
do not exists. Gathering attributes and write them to some meta struct is
not something that is hard to do and work with any attribute even if
compiler have no clue what it mean. I think this fit attributes nicely.



>  So, I was considering proposing the following guidelines:
>>
>>
>>    - Compiler vendor attributes should be disregardable by the compiler.
>>    - Whether a standard attributes can be disregarded should be
>>    evaluated on a per-attribute basis ( for future attributes )
>>    - Attributes unknown to the compiler should be exposed through a
>>    reflection API ( I have yet to think about how such api would look like ).
>>
>> If attributes are exposed to reflection, then *all* attributes should be
> exposed. There's no reason I shouldn't be able to ask if a function is
> `noreturn` or whatever.
>
>>
>>    - Whether standard attributes should be exposed through the
>>    reflection api should be decided on a per attributes basis.
>>    - Contracts should not be exposed through the reflection API.
>>    - All non-standard attributes ( that is, attributes added for
>>    reflection purposes and those offered by vendors) should have a namespace
>>    qualifier. That should be the case already.
>>
>>
>>

--
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/1e0e91af-0794-4e8c-b18a-d8a895d3787f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Saturday, December 30, 2017 at 5:32:02 PM UTC+1=
, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Corentin wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;d like to =
add reflection to the discussion.=C2=A0</div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div><div><div><font=
 color=3D"#212121">In the context of reflection/metaclasses, there needs to=
 be a way to filter entities. Attributes would be a great fit for that.</fo=
nt></div><div><font color=3D"#212121"><br></font></div><div><font color=3D"=
#212121">Some people have suggested that we need a new &quot;decorator&quot=
; feature for that use case. However, such feature would be very similar to=
 attributes but would require a new syntax.</font></div><div><font color=3D=
"#212121">The attribute syntax also offers a lot of great useful features (=
 namespaces, parameters ) that are currently underused, to say the least.</=
font></div><div><font color=3D"#212121"><br></font></div><div>Of course, if=
 people start generating code based on the presence/value of some attribute=
, that confers semantic meaning to the attribute that can therefor not be i=
gnored<font color=3D"#212121"><br></font></div><div>And, that&#39;s okay.</=
div></div></div></div></blockquote><div><br></div><div>That&#39;s a really =
good point. If we can reflect over attributes, then the ability of attribut=
es to be ignored goes away entirely. Or at least, is based on what code som=
eone uses. Even P0840&#39;s idea of saying that &quot;a program that works =
with the use of the attribute shall still behave as a program without that =
attribute&quot; fails, since reflection and code generation based on that w=
ill change.</div><div><br></div><div>So it seems that this makes the curren=
t direction of attributes even less tenable.</div><div><br></div></div></bl=
ockquote><div><br></div><div>IMHO &quot;ignored&quot; in sens that they hav=
e no meaning for compiler not that they do not exists. Gathering attributes=
 and write them to some meta struct is not something that is hard to do and=
 work with any attribute even if compiler have no clue what it mean. I thin=
k this fit attributes nicely.<br></div><div><br></div><div>=C2=A0</div><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"><div></div><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><div><div><font col=
or=3D"#212121">=C2=A0So, I was considering proposing the following guidelin=
es:</font></div><div><font color=3D"#212121"><br></font></div><div><ul><li>=
Compiler vendor attributes should be disregardable by the compiler.=C2=A0</=
li><li>Whether a standard attributes can be disregarded should be evaluated=
 on a per-attribute basis ( for future attributes )</li><li>Attributes unkn=
own to the compiler should be exposed through a reflection API ( I have yet=
 to think about how such api would look like ).</li></ul></div></div></div>=
</div></blockquote><div>If attributes are exposed to reflection, then <i>al=
l</i> attributes should be exposed. There&#39;s no reason I shouldn&#39;t b=
e able to ask if a function is `noreturn` or whatever.</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><ul><li>Whether st=
andard attributes should be exposed through the reflection api should be de=
cided on a per attributes basis.</li><li>Contracts should not be exposed th=
rough the reflection API.</li><li>All non-standard attributes ( that is, at=
tributes added for reflection purposes and those offered by vendors) should=
 have a namespace qualifier. That should be the case already.</li></ul></di=
v></div><div><br></div></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
</blockquote></div></div>
</blockquote></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/1e0e91af-0794-4e8c-b18a-d8a895d3787f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e0e91af-0794-4e8c-b18a-d8a895d3787f=
%40isocpp.org</a>.<br />

------=_Part_31267_766688469.1514657179558--

------=_Part_31266_2016374889.1514657179558--

.

------=_Part_26627_457122334.1514678705983
Content-Type: multipart/alternative;
 boundary="----=_Part_26628_1303219395.1514678705983"

------=_Part_26628_1303219395.1514678705983
Content-Type: text/plain; charset="UTF-8"

On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski wrote:
>
>
> IMHO "ignored" in sens that they have no meaning for compiler not that
> they do not exists. Gathering attributes and write them to some meta struct
> is not something that is hard to do and work with any attribute even if
> compiler have no clue what it mean. I think this fit attributes nicely.
>

No actually, a compiler that would parse-skip c++ attributes would be legal.

--
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/5cf989da-fb68-4c93-8a72-7542f9e437ee%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin=
 Jaczewski wrote:<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"><div><br></div><div>IMHO &quot;ignored&quot; in sens that they have no =
meaning for compiler not that they do not exists. Gathering attributes and =
write them to some meta struct is not something that is hard to do and work=
 with any attribute even if compiler have no clue what it mean. I think thi=
s fit attributes nicely.</div></div></blockquote><div><br></div><div>No act=
ually, a compiler that would parse-skip c++ attributes would be legal.</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/5cf989da-fb68-4c93-8a72-7542f9e437ee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5cf989da-fb68-4c93-8a72-7542f9e437ee=
%40isocpp.org</a>.<br />

------=_Part_26628_1303219395.1514678705983--

------=_Part_26627_457122334.1514678705983--

.

--94eb2c1b5110e036c605619813bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 30, 2017 at 4:05 PM, <bastienpenava@gmail.com> wrote:

> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski wrot=
e:
>>
>>
>> IMHO "ignored" in sens that they have no meaning for compiler not that
>> they do not exists. Gathering attributes and write them to some meta str=
uct
>> is not something that is hard to do and work with any attribute even if
>> compiler have no clue what it mean. I think this fit attributes nicely.
>>
>
> No actually, a compiler that would parse-skip c++ attributes would be
> legal.
>

Legal, sure, but obviously non-conforming. There are plenty of ways that
[[attributes]] can render a translation unit "ill-formed, yes diagnostic
required." A compiler that doesn't check for ill-formed constructs doesn't
conform to the ISO standard... except perhaps in the trivial sense that
[intro.compliance] has no teeth. I'm pretty sure a conforming
implementation could just output "?" in addition to its machine code and
thus satisfy [intro.compliance].

Besides, I think Marcin was probably talking from the point of view of
actual programming. A "legal" compiler could just as well replace the name
of every variable with the output of an MD5 hash, or place an extra
kilobyte of padding between each pair of struct fields, but that doesn't
mean that a hypothetical C++2x reflection facility shouldn't expose things
like variable names and struct layouts. Because the programmer might
actually *want to use* reflection over the names of their variables, or
which attributes have been applied to a function, or struct layout, or
whatever.

=E2=80=93Arthur

--=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/CADvuK0KJmebasr3o5X1QoGNuwKgEO-wOKWXOcfBrOoO2VYk=
aiQ%40mail.gmail.com.

--94eb2c1b5110e036c605619813bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sat, Dec 30, 2017 at 4:05 PM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:bastienpenava@gmail.com" target=3D"_blank">bastienpenava@gm=
ail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"=
">On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><=
div>IMHO &quot;ignored&quot; in sens that they have no meaning for compiler=
 not that they do not exists. Gathering attributes and write them to some m=
eta struct is not something that is hard to do and work with any attribute =
even if compiler have no clue what it mean. I think this fit attributes nic=
ely.</div></div></blockquote><div><br></div></span><div>No actually, a comp=
iler that would parse-skip c++ attributes would be legal.</div></div></bloc=
kquote><div><br></div><div>Legal, sure, but obviously non-conforming. There=
 are plenty of ways that [[attributes]] can render a translation unit &quot=
;ill-formed, yes diagnostic required.&quot; A compiler that doesn&#39;t che=
ck for ill-formed constructs doesn&#39;t conform to the ISO standard... exc=
ept perhaps in the trivial sense that [intro.compliance] has no teeth. I&#3=
9;m pretty sure a conforming implementation could just output &quot;?&quot;=
 in addition to its machine code and thus satisfy [intro.compliance].</div>=
<div><br></div><div>Besides, I think Marcin was probably talking from the p=
oint of view of actual programming. A &quot;legal&quot; compiler could just=
 as well replace the name of every variable with the output of an MD5 hash,=
 or place an extra kilobyte of padding between each pair of struct fields, =
but that doesn&#39;t mean that a hypothetical C++2x reflection facility sho=
uldn&#39;t expose things like variable names and struct layouts. Because th=
e programmer might actually <i>want to use</i> reflection over the names of=
 their variables, or which attributes have been applied to a function, or s=
truct layout, or whatever.</div><div><br></div><div>=E2=80=93Arthur</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&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/CADvuK0KJmebasr3o5X1QoGNuwKgEO-wOKWXO=
cfBrOoO2VYkaiQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADvuK0KJmebasr3o=
5X1QoGNuwKgEO-wOKWXOcfBrOoO2VYkaiQ%40mail.gmail.com</a>.<br />

--94eb2c1b5110e036c605619813bc--

.

------=_Part_31968_246358030.1514693337621
Content-Type: multipart/alternative;
 boundary="----=_Part_31969_1336033319.1514693337622"

------=_Part_31969_1336033319.1514693337622
Content-Type: text/plain; charset="UTF-8"

On Saturday, December 30, 2017 at 1:06:19 PM UTC-5, Marcin Jaczewski wrote:

> On Saturday, December 30, 2017 at 5:32:02 PM UTC+1, Nicol Bolas wrote:
>>
>> On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Corentin wrote:
>>>
>>> I'd like to add reflection to the discussion.
>>>
>>
>>> In the context of reflection/metaclasses, there needs to be a way to
>>> filter entities. Attributes would be a great fit for that.
>>>
>>> Some people have suggested that we need a new "decorator" feature for
>>> that use case. However, such feature would be very similar to attributes
>>> but would require a new syntax.
>>> The attribute syntax also offers a lot of great useful features (
>>> namespaces, parameters ) that are currently underused, to say the least.
>>>
>>> Of course, if people start generating code based on the presence/value
>>> of some attribute, that confers semantic meaning to the attribute that can
>>> therefor not be ignored
>>> And, that's okay.
>>>
>>
>> That's a really good point. If we can reflect over attributes, then the
>> ability of attributes to be ignored goes away entirely. Or at least, is
>> based on what code someone uses. Even P0840's idea of saying that "a
>> program that works with the use of the attribute shall still behave as a
>> program without that attribute" fails, since reflection and code generation
>> based on that will change.
>>
>> So it seems that this makes the current direction of attributes even less
>> tenable.
>>
>>
> IMHO "ignored" in sens that they have no meaning for compiler not that
> they do not exists.
>

But that's* not* the meaning that P0840 wants to have. Its ideas about
attributes are that the compiler is allowed to know they exist, and will
exhibit different behavior in their presence. But if a program would be
legal with those attributes, then the program would be just as legal
without them. The inverse is not what P0840 wants attributes to mean.

Once you start being able to use reflection to detect attributes, then even
P0840's guideline about attributes disappears entirely, since you can now
write programs where this is not the case.

A compiler* cannot ignore* [[no_unique_address]]; it is tied into layout
compatibility rules. A pair of structs that have the same subobject types
declared in the same order are not layout compatible if one uses
[[no_unique_address]] on a member and the other does not. Even if that
member is of a type that can't possibly be empty.

Gathering attributes and write them to some meta struct is not something
> that is hard to do and work with any attribute even if compiler have no
> clue what it mean. I think this fit attributes nicely.
>

--
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/83707744-1213-4ecb-b673-1f6f5704d152%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, December 30, 2017 at 1:06:19 PM UTC-5, Marcin=
 Jaczewski wrote:<br><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">On Saturday, December 30, 2017 at 5:32:02 PM UTC+1, Nicol Bolas wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, =
December 27, 2017 at 5:49:39 PM UTC-5, Corentin 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">I&#39;d like to add reflection to the d=
iscussion.=C2=A0</div></blockquote><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><br></div><div><div><div><font color=3D"#212121">In =
the context of reflection/metaclasses, there needs to be a way to filter en=
tities. Attributes would be a great fit for that.</font></div><div><font co=
lor=3D"#212121"><br></font></div><div><font color=3D"#212121">Some people h=
ave suggested that we need a new &quot;decorator&quot; feature for that use=
 case. However, such feature would be very similar to attributes but would =
require a new syntax.</font></div><div><font color=3D"#212121">The attribut=
e syntax also offers a lot of great useful features ( namespaces, parameter=
s ) that are currently underused, to say the least.</font></div><div><font =
color=3D"#212121"><br></font></div><div>Of course, if people start generati=
ng code based on the presence/value of some attribute, that confers semanti=
c meaning to the attribute that can therefor not be ignored<font color=3D"#=
212121"><br></font></div><div>And, that&#39;s okay.</div></div></div></div>=
</blockquote><div><br></div><div>That&#39;s a really good point. If we can =
reflect over attributes, then the ability of attributes to be ignored goes =
away entirely. Or at least, is based on what code someone uses. Even P0840&=
#39;s idea of saying that &quot;a program that works with the use of the at=
tribute shall still behave as a program without that attribute&quot; fails,=
 since reflection and code generation based on that will change.</div><div>=
<br></div><div>So it seems that this makes the current direction of attribu=
tes even less tenable.</div><div><br></div></div></blockquote><div><br></di=
v><div>IMHO &quot;ignored&quot; in sens that they have no meaning for compi=
ler not that they do not exists.</div></div></blockquote><div><br></div><di=
v>But that&#39;s<i> not</i> the meaning that P0840 wants to have. Its ideas=
 about attributes are that the compiler is allowed to know they exist, and =
will exhibit different behavior in their presence. But if a program would b=
e legal with those attributes, then the program would be just as legal with=
out them. The inverse is not what P0840 wants attributes to mean.</div><div=
><br></div><div>Once you start being able to use reflection to detect attri=
butes, then even P0840&#39;s guideline about attributes disappears entirely=
, since you can now write programs where this is not the case.</div><div><b=
r></div><div>A compiler<i> cannot ignore</i> [[no_unique_address]]; it is t=
ied into layout compatibility rules. A pair of structs that have the same s=
ubobject types declared in the same order are not layout compatible if one =
uses [[no_unique_address]] on a member and the other does not. Even if that=
 member is of a type that can&#39;t possibly be empty.</div><div><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Gatherin=
g attributes and write them to some meta struct is not something that is ha=
rd to do and work with any attribute even if compiler have no clue what it =
mean. I think this fit attributes nicely.<br></div></div></blockquote><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&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/83707744-1213-4ecb-b673-1f6f5704d152%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/83707744-1213-4ecb-b673-1f6f5704d152=
%40isocpp.org</a>.<br />

------=_Part_31969_1336033319.1514693337622--

------=_Part_31968_246358030.1514693337621--

.

------=_Part_31704_1276353088.1514700667928
Content-Type: multipart/alternative;
 boundary="----=_Part_31705_2025923147.1514700667929"

------=_Part_31705_2025923147.1514700667929
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote:
>
> On Sat, Dec 30, 2017 at 4:05 PM, <bastie...@gmail.com <javascript:>>=20
> wrote:
>
>> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski=20
>> wrote:
>>>
>>>
>>> IMHO "ignored" in sens that they have no meaning for compiler not that=
=20
>>> they do not exists. Gathering attributes and write them to some meta st=
ruct=20
>>> is not something that is hard to do and work with any attribute even if=
=20
>>> compiler have no clue what it mean. I think this fit attributes nicely.
>>>
>>
>> No actually, a compiler that would parse-skip c++ attributes would be=20
>> legal.
>>
>
> Legal, sure, but obviously non-conforming. There are plenty of ways that=
=20
> [[attributes]] can render a translation unit "ill-formed, yes diagnostic=
=20
> required." A compiler that doesn't check for ill-formed constructs doesn'=
t=20
> conform to the ISO standard... except perhaps in the trivial sense that=
=20
> [intro.compliance] has no teeth. I'm pretty sure a conforming=20
> implementation could just output "?" in addition to its machine code and=
=20
> thus satisfy [intro.compliance].
>
> Besides, I think Marcin was probably talking from the point of view of=20
> actual programming. A "legal" compiler could just as well replace the nam=
e=20
> of every variable with the output of an MD5 hash, or place an extra=20
> kilobyte of padding between each pair of struct fields, but that doesn't=
=20
> mean that a hypothetical C++2x reflection facility shouldn't expose thing=
s=20
> like variable names and struct layouts. Because the programmer might=20
> actually *want to use* reflection over the names of their variables, or=
=20
> which attributes have been applied to a function, or struct layout, or=20
> whatever.
>
> =E2=80=93Arthur
>
Yes it would and I use legal to express "minimum required to be compliant".
By parse-skip I meant that the declaration's internal representation is=20
allowed not to contain/save non-recognized attributes.
A compiler that would not-recognize "noreturn" for instance would still be=
=20
compliant as the current standard defined attributes are allowed to be=20
ignored (their ill-form use as well).
A compiler that would hash into MD5 the variables name would clash=20
explicitly with the reflection proposals.

My point was that completely ignoring unrecognized attributes (which is=20
compliant) can change the result of a computation with reflection:

struct A
{
   [[my_undefined_attribute]] int i;
};

for (auto x : reflexpr(A).member_variables())
{
    if (x.has_attribute("my_undefined_attribute"))
       behaviour_a();
   else
       behaviour_b();
}

--=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/826fe303-b6b8-4a78-a9a8-2134a2001b8e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, =
Arthur O&#39;Dwyer 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 Sat, Dec 30, 2017 at 4:05 PM,  <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"qp5g5LnyCQAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">bastie...@gm=
ail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><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"><span>On Saturday, December 30, 2017 =
at 7:06:19 PM UTC+1, Marcin Jaczewski wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div><br></div><div>IMHO &quot;ignored&quot; in s=
ens that they have no meaning for compiler not that they do not exists. Gat=
hering attributes and write them to some meta struct is not something that =
is hard to do and work with any attribute even if compiler have no clue wha=
t it mean. I think this fit attributes nicely.</div></div></blockquote><div=
><br></div></span><div>No actually, a compiler that would parse-skip c++ at=
tributes would be legal.</div></div></blockquote><div><br></div><div>Legal,=
 sure, but obviously non-conforming. There are plenty of ways that [[attrib=
utes]] can render a translation unit &quot;ill-formed, yes diagnostic requi=
red.&quot; A compiler that doesn&#39;t check for ill-formed constructs does=
n&#39;t conform to the ISO standard... except perhaps in the trivial sense =
that [intro.compliance] has no teeth. I&#39;m pretty sure a conforming impl=
ementation could just output &quot;?&quot; in addition to its machine code =
and thus satisfy [intro.compliance].</div><div><br></div><div>Besides, I th=
ink Marcin was probably talking from the point of view of actual programmin=
g. A &quot;legal&quot; compiler could just as well replace the name of ever=
y variable with the output of an MD5 hash, or place an extra kilobyte of pa=
dding between each pair of struct fields, but that doesn&#39;t mean that a =
hypothetical C++2x reflection facility shouldn&#39;t expose things like var=
iable names and struct layouts. Because the programmer might actually <i>wa=
nt to use</i> reflection over the names of their variables, or which attrib=
utes have been applied to a function, or struct layout, or whatever.</div><=
div><br></div><div>=E2=80=93Arthur</div></div></div></div></blockquote><div=
>Yes it would and I use legal to express &quot;minimum required to be compl=
iant&quot;.</div><div>By parse-skip I meant that the declaration&#39;s inte=
rnal representation is allowed not to contain/save non-recognized attribute=
s.<br></div><div>A compiler that would not-recognize &quot;noreturn&quot; f=
or instance would still be compliant as the current standard defined attrib=
utes are allowed to be ignored (their ill-form use as well).</div><div>A co=
mpiler that would hash into MD5 the variables name would clash explicitly w=
ith the reflection proposals.</div><div><br></div><div>My point was that co=
mpletely ignoring unrecognized attributes (which is compliant) can change t=
he result of a computation with reflection:</div><div><br></div><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> A<br></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 =C2=A0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">my_undefined_attribute</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">]]</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">for</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=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">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> reflexpr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">A</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">).</span><span style=3D"color: #000;" class=3D"styled-by-prettify">me=
mber_variables</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">())</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></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 =C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #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">has_attribute</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&quot;my_undefined_attribute&quot;</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour_a</=
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 =C2=A0</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">else</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0behaviour_b</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span></div></code></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/826fe303-b6b8-4a78-a9a8-2134a2001b8e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/826fe303-b6b8-4a78-a9a8-2134a2001b8e=
%40isocpp.org</a>.<br />

------=_Part_31705_2025923147.1514700667929--

------=_Part_31704_1276353088.1514700667928--

.

------=_Part_32890_853153641.1514733129848
Content-Type: multipart/alternative;
 boundary="----=_Part_32891_90457681.1514733129848"

------=_Part_32891_90457681.1514733129848
Content-Type: text/plain; charset="UTF-8"



On Sunday, December 31, 2017 at 5:08:57 AM UTC+1, Nicol Bolas wrote:
>
> On Saturday, December 30, 2017 at 1:06:19 PM UTC-5, Marcin Jaczewski wrote:
>
>> On Saturday, December 30, 2017 at 5:32:02 PM UTC+1, Nicol Bolas wrote:
>>>
>>> On Wednesday, December 27, 2017 at 5:49:39 PM UTC-5, Corentin wrote:
>>>>
>>>> I'd like to add reflection to the discussion.
>>>>
>>>
>>>> In the context of reflection/metaclasses, there needs to be a way to
>>>> filter entities. Attributes would be a great fit for that.
>>>>
>>>> Some people have suggested that we need a new "decorator" feature for
>>>> that use case. However, such feature would be very similar to attributes
>>>> but would require a new syntax.
>>>> The attribute syntax also offers a lot of great useful features (
>>>> namespaces, parameters ) that are currently underused, to say the least.
>>>>
>>>> Of course, if people start generating code based on the presence/value
>>>> of some attribute, that confers semantic meaning to the attribute that can
>>>> therefor not be ignored
>>>> And, that's okay.
>>>>
>>>
>>> That's a really good point. If we can reflect over attributes, then the
>>> ability of attributes to be ignored goes away entirely. Or at least, is
>>> based on what code someone uses. Even P0840's idea of saying that "a
>>> program that works with the use of the attribute shall still behave as a
>>> program without that attribute" fails, since reflection and code generation
>>> based on that will change.
>>>
>>> So it seems that this makes the current direction of attributes even
>>> less tenable.
>>>
>>>
>> IMHO "ignored" in sens that they have no meaning for compiler not that
>> they do not exists.
>>
>
> But that's* not* the meaning that P0840 wants to have. Its ideas about
> attributes are that the compiler is allowed to know they exist, and will
> exhibit different behavior in their presence. But if a program would be
> legal with those attributes, then the program would be just as legal
> without them. The inverse is not what P0840 wants attributes to mean.
>
> Once you start being able to use reflection to detect attributes, then
> even P0840's guideline about attributes disappears entirely, since you can
> now write programs where this is not the case.
>
> A compiler* cannot ignore* [[no_unique_address]]; it is tied into layout
> compatibility rules. A pair of structs that have the same subobject types
> declared in the same order are not layout compatible if one uses
> [[no_unique_address]] on a member and the other does not. Even if that
> member is of a type that can't possibly be empty.
>
> Gathering attributes and write them to some meta struct is not something
>> that is hard to do and work with any attribute even if compiler have no
>> clue what it mean. I think this fit attributes nicely.
>>
>
>

But even attribute from P0840 can by ignored. Consider that we have correct
program that have use this attribute and compile on compiler that do not
implements this attribute but return it through reflection (my definition
of "ignored").
In that program we have written custom type traits that check for layout
compatibility of two struct, it check for each member if he have this
attribute. If compiler do not implements this attribute this trait will
return false negative but this is cause same behavior as on other compiler
that implemented this attribute.
This will be similar to `int` and `long` types, on some machines are
effective same type but compiler treats them differently, same as with our
custom type traits it will report that two struct are incompatible if is
incompatible on other implementations.

Other situation is when we write incorrect program that break P0840 rules.
For example we `std::memcpy` two not layout compatible structs because of
use of this attribute, then we have UB. Even compiler that implements this
attribute could not detect this. As this is UB, old behavior is still
allowed as result of this `std::memcpy`.

This is exactly same situation as with `[[noreturn]]`, when you add it to
random function then you get UB if it returns. Old compilers will work same
as before, new will create code that will crash.
When we add [[no_unique_address]] to one struct and `memcpy` incompatible
structs without it then we have again UB. Old compilers will work same as
before (because this struct are still compatible), new will create code
that will crash.

BTW `std::is_empty` even if compiler implements P0840 can have current
behavior. This is probably not what P0840 want but still allowed as this is
implementation defined.

--
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/cf7059ec-7c3b-4992-9844-ebe69150b658%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, December 31, 2017 at 5:08:57 AM UTC+1, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Saturday, December 30, 2017 at 1:06:19 PM UTC-5, Marcin Jaczewski 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">On Saturd=
ay, December 30, 2017 at 5:32:02 PM UTC+1, Nicol Bolas wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, December 27, 2017 =
at 5:49:39 PM UTC-5, Corentin 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">I&#39;d like to add reflection to the discussion.=C2=A0</=
div></blockquote><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><br></div><div><div><div><font color=3D"#212121">In the context of refl=
ection/metaclasses, there needs to be a way to filter entities. Attributes =
would be a great fit for that.</font></div><div><font color=3D"#212121"><br=
></font></div><div><font color=3D"#212121">Some people have suggested that =
we need a new &quot;decorator&quot; feature for that use case. However, suc=
h feature would be very similar to attributes but would require a new synta=
x.</font></div><div><font color=3D"#212121">The attribute syntax also offer=
s a lot of great useful features ( namespaces, parameters ) that are curren=
tly underused, to say the least.</font></div><div><font color=3D"#212121"><=
br></font></div><div>Of course, if people start generating code based on th=
e presence/value of some attribute, that confers semantic meaning to the at=
tribute that can therefor not be ignored<font color=3D"#212121"><br></font>=
</div><div>And, that&#39;s okay.</div></div></div></div></blockquote><div><=
br></div><div>That&#39;s a really good point. If we can reflect over attrib=
utes, then the ability of attributes to be ignored goes away entirely. Or a=
t least, is based on what code someone uses. Even P0840&#39;s idea of sayin=
g that &quot;a program that works with the use of the attribute shall still=
 behave as a program without that attribute&quot; fails, since reflection a=
nd code generation based on that will change.</div><div><br></div><div>So i=
t seems that this makes the current direction of attributes even less tenab=
le.</div><div><br></div></div></blockquote><div><br></div><div>IMHO &quot;i=
gnored&quot; in sens that they have no meaning for compiler not that they d=
o not exists.</div></div></blockquote><div><br></div><div>But that&#39;s<i>=
 not</i> the meaning that P0840 wants to have. Its ideas about attributes a=
re that the compiler is allowed to know they exist, and will exhibit differ=
ent behavior in their presence. But if a program would be legal with those =
attributes, then the program would be just as legal without them. The inver=
se is not what P0840 wants attributes to mean.</div><div><br></div><div>Onc=
e you start being able to use reflection to detect attributes, then even P0=
840&#39;s guideline about attributes disappears entirely, since you can now=
 write programs where this is not the case.</div><div><br></div><div>A comp=
iler<i> cannot ignore</i> [[no_unique_address]]; it is tied into layout com=
patibility rules. A pair of structs that have the same subobject types decl=
ared in the same order are not layout compatible if one uses [[no_unique_ad=
dress]] on a member and the other does not. Even if that member is of a typ=
e that can&#39;t possibly be empty.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>Gathering attributes and write=
 them to some meta struct is not something that is hard to do and work with=
 any attribute even if compiler have no clue what it mean. I think this fit=
 attributes nicely.<br></div></div></blockquote><div><br></div></div></bloc=
kquote><div>=C2=A0</div><div><br></div><div>But even attribute from P0840 c=
an by ignored. Consider that we have correct program that have use this att=
ribute and compile on compiler that do not implements this attribute but re=
turn it through reflection (my definition of &quot;ignored&quot;).</div><di=
v>In that program we have written custom type traits that check for layout =
compatibility of two struct, it check for each member if he have this attri=
bute. If compiler do not implements this attribute this trait will return f=
alse negative but this is cause same behavior as on other compiler that imp=
lemented this attribute.</div><div> This will be similar to `int` and `long=
` types, on some machines are effective same type but compiler treats them =
differently, same as with our custom type traits it will report that two st=
ruct are incompatible if is incompatible on other implementations.</div><di=
v><br></div><div>Other situation is when we write incorrect program that br=
eak P0840 rules. For example we `std::memcpy` two not layout compatible str=
ucts because of use of this attribute, then we have UB. Even compiler that =
implements this attribute could not detect this. As this is UB, old behavio=
r is still allowed as result of this `std::memcpy`.</div><div><br></div><di=
v>This is exactly same situation as with `[[noreturn]]`, when you add it to=
 random function then you get UB if it returns. Old compilers will work sam=
e as before, new will create code that will crash.</div><div>When we add [[=
no_unique_address]] to one struct and `memcpy` incompatible structs without=
 it then we have again UB. Old compilers will work same as before (because =
this struct are still compatible), new will create code that will crash.</d=
iv><div><br></div><div>BTW `std::is_empty` even if compiler implements P084=
0 can have current behavior. This is probably not what P0840 want but still=
 allowed as this is implementation defined.<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/cf7059ec-7c3b-4992-9844-ebe69150b658%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cf7059ec-7c3b-4992-9844-ebe69150b658=
%40isocpp.org</a>.<br />

------=_Part_32891_90457681.1514733129848--

------=_Part_32890_853153641.1514733129848--

.

------=_Part_25247_2124238103.1514735938350
Content-Type: multipart/alternative;
 boundary="----=_Part_25248_92240096.1514735938350"

------=_Part_25248_92240096.1514735938350
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, bastie...@gmail.com wrote=
:
>
>
>
> On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote:
>>
>> On Sat, Dec 30, 2017 at 4:05 PM, <bastie...@gmail.com> wrote:
>>
>>> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski=20
>>> wrote:
>>>>
>>>>
>>>> IMHO "ignored" in sens that they have no meaning for compiler not that=
=20
>>>> they do not exists. Gathering attributes and write them to some meta s=
truct=20
>>>> is not something that is hard to do and work with any attribute even i=
f=20
>>>> compiler have no clue what it mean. I think this fit attributes nicely=
..
>>>>
>>>
>>> No actually, a compiler that would parse-skip c++ attributes would be=
=20
>>> legal.
>>>
>>
>> Legal, sure, but obviously non-conforming. There are plenty of ways that=
=20
>> [[attributes]] can render a translation unit "ill-formed, yes diagnostic=
=20
>> required." A compiler that doesn't check for ill-formed constructs doesn=
't=20
>> conform to the ISO standard... except perhaps in the trivial sense that=
=20
>> [intro.compliance] has no teeth. I'm pretty sure a conforming=20
>> implementation could just output "?" in addition to its machine code and=
=20
>> thus satisfy [intro.compliance].
>>
>> Besides, I think Marcin was probably talking from the point of view of=
=20
>> actual programming. A "legal" compiler could just as well replace the na=
me=20
>> of every variable with the output of an MD5 hash, or place an extra=20
>> kilobyte of padding between each pair of struct fields, but that doesn't=
=20
>> mean that a hypothetical C++2x reflection facility shouldn't expose thin=
gs=20
>> like variable names and struct layouts. Because the programmer might=20
>> actually *want to use* reflection over the names of their variables, or=
=20
>> which attributes have been applied to a function, or struct layout, or=
=20
>> whatever.
>>
>> =E2=80=93Arthur
>>
> Yes it would and I use legal to express "minimum required to be compliant=
".
> By parse-skip I meant that the declaration's internal representation is=
=20
> allowed not to contain/save non-recognized attributes.
> A compiler that would not-recognize "noreturn" for instance would still b=
e=20
> compliant as the current standard defined attributes are allowed to be=20
> ignored (their ill-form use as well).
> A compiler that would hash into MD5 the variables name would clash=20
> explicitly with the reflection proposals.
>
> My point was that completely ignoring unrecognized attributes (which is=
=20
> compliant) can change the result of a computation with reflection:
>
> struct A
> {
>    [[my_undefined_attribute]] int i;
> };
>
> for (auto x : reflexpr(A).member_variables())
> {
>     if (x.has_attribute("my_undefined_attribute"))
>        behaviour_a();
>    else
>        behaviour_b();
> }
>
=20
Again:=20
> IMHO "ignored" in sens that they have no meaning for compiler not that=20
they do not exists
This is not statement about how it now behave but how it should behave.
When reflection hits then we can require for complying implementation that=
=20
it store ALL attributes for reflection purposes and nothing more.
They will be still "ignored" because will not affect any thing else in=20
compiler.

--=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/9175685e-4a44-4e1f-afc9-f8271aa63deb%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, =
bastie...@gmail.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><br>On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arth=
ur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">On Sat, Dec 30, 2017 at 4:05 PM,  <span dir=3D"ltr">&lt;<a rel=3D"nofoll=
ow">bastie...@gmail.com</a>&gt;</span> wrote:<br><div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Saturday, De=
cember 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski wrote:<blockquote cla=
ss=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>IMHO &quot;ig=
nored&quot; in sens that they have no meaning for compiler not that they do=
 not exists. Gathering attributes and write them to some meta struct is not=
 something that is hard to do and work with any attribute even if compiler =
have no clue what it mean. I think this fit attributes nicely.</div></div><=
/blockquote><div><br></div></span><div>No actually, a compiler that would p=
arse-skip c++ attributes would be legal.</div></div></blockquote><div><br><=
/div><div>Legal, sure, but obviously non-conforming. There are plenty of wa=
ys that [[attributes]] can render a translation unit &quot;ill-formed, yes =
diagnostic required.&quot; A compiler that doesn&#39;t check for ill-formed=
 constructs doesn&#39;t conform to the ISO standard... except perhaps in th=
e trivial sense that [intro.compliance] has no teeth. I&#39;m pretty sure a=
 conforming implementation could just output &quot;?&quot; in addition to i=
ts machine code and thus satisfy [intro.compliance].</div><div><br></div><d=
iv>Besides, I think Marcin was probably talking from the point of view of a=
ctual programming. A &quot;legal&quot; compiler could just as well replace =
the name of every variable with the output of an MD5 hash, or place an extr=
a kilobyte of padding between each pair of struct fields, but that doesn&#3=
9;t mean that a hypothetical C++2x reflection facility shouldn&#39;t expose=
 things like variable names and struct layouts. Because the programmer migh=
t actually <i>want to use</i> reflection over the names of their variables,=
 or which attributes have been applied to a function, or struct layout, or =
whatever.</div><div><br></div><div>=E2=80=93Arthur</div></div></div></div><=
/blockquote><div>Yes it would and I use legal to express &quot;minimum requ=
ired to be compliant&quot;.</div><div>By parse-skip I meant that the declar=
ation&#39;s internal representation is allowed not to contain/save non-reco=
gnized attributes.<br></div><div>A compiler that would not-recognize &quot;=
noreturn&quot; for instance would still be compliant as the current standar=
d defined attributes are allowed to be ignored (their ill-form use as well)=
..</div><div>A compiler that would hash into MD5 the variables name would cl=
ash explicitly with the reflection proposals.</div><div><br></div><div>My p=
oint was that completely ignoring unrecognized attributes (which is complia=
nt) can change the result of a computation with reflection:</div><div><br><=
/div><div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,1=
87,187);border-style:solid;border-width:1px;word-wrap:break-word"><code><di=
v><span style=3D"color:#008">struct</span><span style=3D"color:#000"> A<br>=
</span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0</span><span style=3D"color:#660">[[</span><span style=3D"colo=
r:#000">my_undefined_attribute</span><span style=3D"color:#660">]]</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#008">int</span><span=
 style=3D"color:#000"> i</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span styl=
e=3D"color:#000"><br><br></span><span style=3D"color:#008">for</span><span =
style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span style=
=3D"color:#008">auto</span><span style=3D"color:#000"> x </span><span style=
=3D"color:#660">:</span><span style=3D"color:#000"> reflexpr</span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">A</span><span style=
=3D"color:#660">).</span><span style=3D"color:#000">member_variables</span>=
<span style=3D"color:#660">()<wbr>)</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#008">if</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">(</span><span style=3D"color:#000"=
>x</span><span style=3D"color:#660">.</span><span style=3D"color:#000">has_=
attribute</span><span style=3D"color:#660">(</span><span style=3D"color:#08=
0">&quot;my_<wbr>undefined_attribute&quot;</span><span style=3D"color:#660"=
>))</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0behavio=
ur_a</span><span style=3D"color:#660">();</span><span style=3D"color:#000">=
<br>=C2=A0 =C2=A0</span><span style=3D"color:#008">else</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour_b</span><span styl=
e=3D"color:#660">();</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">}</span></div></code></div></div></blockquote><div>=C2=A0<=
/div><div>Again: <br></div><div>&gt; IMHO &quot;ignored&quot; in sens that =
they have no meaning for compiler not that they do not exists</div><div> Th=
is is not statement about how it now behave but how it should behave.</div>=
<div>When reflection hits then we can require for complying implementation =
that it store ALL attributes for reflection purposes and nothing more.</div=
><div>They will be still &quot;ignored&quot; because will not affect any th=
ing else in compiler.<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/9175685e-4a44-4e1f-afc9-f8271aa63deb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9175685e-4a44-4e1f-afc9-f8271aa63deb=
%40isocpp.org</a>.<br />

------=_Part_25248_92240096.1514735938350--

------=_Part_25247_2124238103.1514735938350--

.

------=_Part_32946_1515073130.1514737278872
Content-Type: multipart/alternative;
 boundary="----=_Part_32947_1998488120.1514737278873"

------=_Part_32947_1998488120.1514737278873
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski wrote:
>
> On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, bastie...@gmail.com=20
> wrote:
>>
>> On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote:
>>>
>>> On Sat, Dec 30, 2017 at 4:05 PM, <bastie...@gmail.com> wrote:
>>>
>>>> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski=
=20
>>>> wrote:
>>>>>
>>>>>
>>>>> IMHO "ignored" in sens that they have no meaning for compiler not tha=
t=20
>>>>> they do not exists. Gathering attributes and write them to some meta =
struct=20
>>>>> is not something that is hard to do and work with any attribute even =
if=20
>>>>> compiler have no clue what it mean. I think this fit attributes nicel=
y.
>>>>>
>>>>
>>>> No actually, a compiler that would parse-skip c++ attributes would be=
=20
>>>> legal.
>>>>
>>>
>>> Legal, sure, but obviously non-conforming. There are plenty of ways tha=
t=20
>>> [[attributes]] can render a translation unit "ill-formed, yes diagnosti=
c=20
>>> required." A compiler that doesn't check for ill-formed constructs does=
n't=20
>>> conform to the ISO standard... except perhaps in the trivial sense that=
=20
>>> [intro.compliance] has no teeth. I'm pretty sure a conforming=20
>>> implementation could just output "?" in addition to its machine code an=
d=20
>>> thus satisfy [intro.compliance].
>>>
>>> Besides, I think Marcin was probably talking from the point of view of=
=20
>>> actual programming. A "legal" compiler could just as well replace the n=
ame=20
>>> of every variable with the output of an MD5 hash, or place an extra=20
>>> kilobyte of padding between each pair of struct fields, but that doesn'=
t=20
>>> mean that a hypothetical C++2x reflection facility shouldn't expose thi=
ngs=20
>>> like variable names and struct layouts. Because the programmer might=20
>>> actually *want to use* reflection over the names of their variables, or=
=20
>>> which attributes have been applied to a function, or struct layout, or=
=20
>>> whatever.
>>>
>>> =E2=80=93Arthur
>>>
>> Yes it would and I use legal to express "minimum required to be=20
>> compliant".
>> By parse-skip I meant that the declaration's internal representation is=
=20
>> allowed not to contain/save non-recognized attributes.
>> A compiler that would not-recognize "noreturn" for instance would still=
=20
>> be compliant as the current standard defined attributes are allowed to b=
e=20
>> ignored (their ill-form use as well).
>> A compiler that would hash into MD5 the variables name would clash=20
>> explicitly with the reflection proposals.
>>
>> My point was that completely ignoring unrecognized attributes (which is=
=20
>> compliant) can change the result of a computation with reflection:
>>
>> struct A
>> {
>>    [[my_undefined_attribute]] int i;
>> };
>>
>> for (auto x : reflexpr(A).member_variables())
>> {
>>     if (x.has_attribute("my_undefined_attribute"))
>>        behaviour_a();
>>    else
>>        behaviour_b();
>> }
>>
> =20
> Again:=20
> > IMHO "ignored" in sens that they have no meaning for compiler not that=
=20
> they do not exists
> This is not statement about how it now behave but how it should behave.
> When reflection hits then we can require for complying implementation tha=
t=20
> it store ALL attributes for reflection purposes and nothing more.
> They will be still "ignored" because will not affect any thing else in=20
> compiler.
>

Can you not see that, for the programmer, this is a distinction without a=
=20
distinction? If something affects the standard-defined behavior of the=20
program, the programmer doesn't care if it's the compiler doing it or some=
=20
particular code that's causing that behavior. And therefore, for the=20
programmer, an attribute and a keyword are equally significant.

Who cares if the "compiler" is allowed to "ignore" it, when the compiler is=
*=20
required* to pass that information along to other code which will not=20
ignore it? That's not ignoring it; that's not everything works as it did=20
before.

--=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/9389c26c-b1a4-4790-8181-1e1c386a8ff8%40isocpp.or=
g.

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

<div dir=3D"ltr">On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin =
Jaczewski 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"lt=
r">On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, <a>bastie...@gmail.com=
</a> 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 Sund=
ay, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O&#39;Dwyer wrote:<blockq=
uote 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 Sat, Dec 30, 2017 at 4=
:05 PM,  <span dir=3D"ltr">&lt;<a rel=3D"nofollow">bastie...@gmail.com</a>&=
gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><span>On Saturday, December 30, 2017 at 7:06:19 P=
M UTC+1, Marcin Jaczewski wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div><br></div><div>IMHO &quot;ignored&quot; in sens that the=
y have no meaning for compiler not that they do not exists. Gathering attri=
butes and write them to some meta struct is not something that is hard to d=
o and work with any attribute even if compiler have no clue what it mean. I=
 think this fit attributes nicely.</div></div></blockquote><div><br></div><=
/span><div>No actually, a compiler that would parse-skip c++ attributes wou=
ld be legal.</div></div></blockquote><div><br></div><div>Legal, sure, but o=
bviously non-conforming. There are plenty of ways that [[attributes]] can r=
ender a translation unit &quot;ill-formed, yes diagnostic required.&quot; A=
 compiler that doesn&#39;t check for ill-formed constructs doesn&#39;t conf=
orm to the ISO standard... except perhaps in the trivial sense that [intro.=
compliance] has no teeth. I&#39;m pretty sure a conforming implementation c=
ould just output &quot;?&quot; in addition to its machine code and thus sat=
isfy [intro.compliance].</div><div><br></div><div>Besides, I think Marcin w=
as probably talking from the point of view of actual programming. A &quot;l=
egal&quot; compiler could just as well replace the name of every variable w=
ith the output of an MD5 hash, or place an extra kilobyte of padding betwee=
n each pair of struct fields, but that doesn&#39;t mean that a hypothetical=
 C++2x reflection facility shouldn&#39;t expose things like variable names =
and struct layouts. Because the programmer might actually <i>want to use</i=
> reflection over the names of their variables, or which attributes have be=
en applied to a function, or struct layout, or whatever.</div><div><br></di=
v><div>=E2=80=93Arthur</div></div></div></div></blockquote><div>Yes it woul=
d and I use legal to express &quot;minimum required to be compliant&quot;.<=
/div><div>By parse-skip I meant that the declaration&#39;s internal represe=
ntation is allowed not to contain/save non-recognized attributes.<br></div>=
<div>A compiler that would not-recognize &quot;noreturn&quot; for instance =
would still be compliant as the current standard defined attributes are all=
owed to be ignored (their ill-form use as well).</div><div>A compiler that =
would hash into MD5 the variables name would clash explicitly with the refl=
ection proposals.</div><div><br></div><div>My point was that completely ign=
oring unrecognized attributes (which is compliant) can change the result of=
 a computation with reflection:</div><div><br></div><div style=3D"backgroun=
d-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;b=
order-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008"=
>struct</span><span style=3D"color:#000"> A<br></span><span style=3D"color:=
#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span styl=
e=3D"color:#660">[[</span><span style=3D"color:#000">my_undefined_attribute=
</span><span style=3D"color:#660">]]</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#000"> i</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><=
span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br></spa=
n><span style=3D"color:#008">for</span><span style=3D"color:#000"> </span><=
span style=3D"color:#660">(</span><span style=3D"color:#008">auto</span><sp=
an style=3D"color:#000"> x </span><span style=3D"color:#660">:</span><span =
style=3D"color:#000"> reflexpr</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#000">A</span><span style=3D"color:#660">).</span><span s=
tyle=3D"color:#000">member_variables</span><span style=3D"color:#660">()<wb=
r>)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color:#008">if</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">(</span><span style=3D"color:#000">x</span><span style=3D"color:#66=
0">.</span><span style=3D"color:#000">has_attribute</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#080">&quot;my_<wbr>undefined_attrib=
ute&quot;</span><span style=3D"color:#660">))</span><span style=3D"color:#0=
00"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour_a</span><span style=3D"color:#=
660">();</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span sty=
le=3D"color:#008">else</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0behaviour_b</span><span style=3D"color:#660">();</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#660">}</span></div></c=
ode></div></div></blockquote><div>=C2=A0</div><div>Again: <br></div><div>&g=
t; IMHO &quot;ignored&quot; in sens that they have no meaning for compiler =
not that they do not exists</div><div> This is not statement about how it n=
ow behave but how it should behave.</div><div>When reflection hits then we =
can require for complying implementation that it store ALL attributes for r=
eflection purposes and nothing more.</div><div>They will be still &quot;ign=
ored&quot; because will not affect any thing else in compiler.<br></div></d=
iv></blockquote><div><br></div><div>Can you not see that, for the programme=
r, this is a distinction without a distinction? If something affects the st=
andard-defined behavior of the program, the programmer doesn&#39;t care if =
it&#39;s the compiler doing it or some particular code that&#39;s causing t=
hat behavior. And therefore, for the programmer, an attribute and a keyword=
 are equally significant.</div><div><br></div><div>Who cares if the &quot;c=
ompiler&quot; is allowed to &quot;ignore&quot; it, when the compiler is<i> =
required</i> to pass that information along to other code which will not ig=
nore it? That&#39;s not ignoring it; that&#39;s not everything works as it =
did before.</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/9389c26c-b1a4-4790-8181-1e1c386a8ff8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9389c26c-b1a4-4790-8181-1e1c386a8ff8=
%40isocpp.org</a>.<br />

------=_Part_32947_1998488120.1514737278873--

------=_Part_32946_1515073130.1514737278872--

.

------=_Part_32652_823143596.1514738553902
Content-Type: multipart/alternative;
 boundary="----=_Part_32653_878646439.1514738553902"

------=_Part_32653_878646439.1514738553902
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



On Sunday, December 31, 2017 at 5:21:18 PM UTC+1, Nicol Bolas wrote:
>
> On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski wrote=
:
>>
>> On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, bastie...@gmail.com=20
>> wrote:
>>>
>>> On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote:
>>>>
>>>> On Sat, Dec 30, 2017 at 4:05 PM, <bastie...@gmail.com> wrote:
>>>>
>>>>> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski=
=20
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> IMHO "ignored" in sens that they have no meaning for compiler not=20
>>>>>> that they do not exists. Gathering attributes and write them to some=
 meta=20
>>>>>> struct is not something that is hard to do and work with any attribu=
te even=20
>>>>>> if compiler have no clue what it mean. I think this fit attributes n=
icely.
>>>>>>
>>>>>
>>>>> No actually, a compiler that would parse-skip c++ attributes would be=
=20
>>>>> legal.
>>>>>
>>>>
>>>> Legal, sure, but obviously non-conforming. There are plenty of ways=20
>>>> that [[attributes]] can render a translation unit "ill-formed, yes=20
>>>> diagnostic required." A compiler that doesn't check for ill-formed=20
>>>> constructs doesn't conform to the ISO standard... except perhaps in th=
e=20
>>>> trivial sense that [intro.compliance] has no teeth. I'm pretty sure a=
=20
>>>> conforming implementation could just output "?" in addition to its mac=
hine=20
>>>> code and thus satisfy [intro.compliance].
>>>>
>>>> Besides, I think Marcin was probably talking from the point of view of=
=20
>>>> actual programming. A "legal" compiler could just as well replace the =
name=20
>>>> of every variable with the output of an MD5 hash, or place an extra=20
>>>> kilobyte of padding between each pair of struct fields, but that doesn=
't=20
>>>> mean that a hypothetical C++2x reflection facility shouldn't expose th=
ings=20
>>>> like variable names and struct layouts. Because the programmer might=
=20
>>>> actually *want to use* reflection over the names of their variables,=
=20
>>>> or which attributes have been applied to a function, or struct layout,=
 or=20
>>>> whatever.
>>>>
>>>> =E2=80=93Arthur
>>>>
>>> Yes it would and I use legal to express "minimum required to be=20
>>> compliant".
>>> By parse-skip I meant that the declaration's internal representation is=
=20
>>> allowed not to contain/save non-recognized attributes.
>>> A compiler that would not-recognize "noreturn" for instance would still=
=20
>>> be compliant as the current standard defined attributes are allowed to =
be=20
>>> ignored (their ill-form use as well).
>>> A compiler that would hash into MD5 the variables name would clash=20
>>> explicitly with the reflection proposals.
>>>
>>> My point was that completely ignoring unrecognized attributes (which is=
=20
>>> compliant) can change the result of a computation with reflection:
>>>
>>> struct A
>>> {
>>>    [[my_undefined_attribute]] int i;
>>> };
>>>
>>> for (auto x : reflexpr(A).member_variables())
>>> {
>>>     if (x.has_attribute("my_undefined_attribute"))
>>>        behaviour_a();
>>>    else
>>>        behaviour_b();
>>> }
>>>
>> =20
>> Again:=20
>> > IMHO "ignored" in sens that they have no meaning for compiler not that=
=20
>> they do not exists
>> This is not statement about how it now behave but how it should behave.
>> When reflection hits then we can require for complying implementation=20
>> that it store ALL attributes for reflection purposes and nothing more.
>> They will be still "ignored" because will not affect any thing else in=
=20
>> compiler.
>>
>
> Can you not see that, for the programmer, this is a distinction without a=
=20
> distinction? If something affects the standard-defined behavior of the=20
> program, the programmer doesn't care if it's the compiler doing it or som=
e=20
> particular code that's causing that behavior. And therefore, for the=20
> programmer, an attribute and a keyword are equally significant.
>
> Who cares if the "compiler" is allowed to "ignore" it, when the compiler =
is*=20
> required* to pass that information along to other code which will not=20
> ignore it? That's not ignoring it; that's not everything works as it did=
=20
> before.
>
=20
This is why I use quotes in "ignore". Overall this behavior what you=20
describe is how I see attributes. As contract between programmers. Compiler=
=20
can use it but is not required. Programmer must obey it even if compiler do=
=20
not implements it. We could even name it as "optional keywords" because as=
=20
you point out they are for programmers equally significant.

Overall attributes can create new dialects of C++ but if we keep rule that=
=20
they all can be "ignored" (quotes!) by compiler and behavior should be same=
=20
then I could grab any compiler and any valid program and result will be=20
same. Even if it was written in some dialect of C++ crated by attributes.

--=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/bb33d3d8-d2a3-4f8f-a4f9-eb221e5790ea%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Sunday, December 31, 2017 at 5:21:18 PM UTC+1, =
Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, Dec=
ember 31, 2017 at 7:11:08 AM UTC+1, <a>bastie...@gmail.com</a> 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">On Sunday, December 31, =
2017 at 1:38:02 AM UTC+1, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">On Sat, Dec 30, 2017 at 4:05 PM,  <span di=
r=3D"ltr">&lt;<a rel=3D"nofollow">bastie...@gmail.com</a>&gt;</span> wrote:=
<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span>On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin J=
aczewski 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"><di=
v><br></div><div>IMHO &quot;ignored&quot; in sens that they have no meaning=
 for compiler not that they do not exists. Gathering attributes and write t=
hem to some meta struct is not something that is hard to do and work with a=
ny attribute even if compiler have no clue what it mean. I think this fit a=
ttributes nicely.</div></div></blockquote><div><br></div></span><div>No act=
ually, a compiler that would parse-skip c++ attributes would be legal.</div=
></div></blockquote><div><br></div><div>Legal, sure, but obviously non-conf=
orming. There are plenty of ways that [[attributes]] can render a translati=
on unit &quot;ill-formed, yes diagnostic required.&quot; A compiler that do=
esn&#39;t check for ill-formed constructs doesn&#39;t conform to the ISO st=
andard... except perhaps in the trivial sense that [intro.compliance] has n=
o teeth. I&#39;m pretty sure a conforming implementation could just output =
&quot;?&quot; in addition to its machine code and thus satisfy [intro.compl=
iance].</div><div><br></div><div>Besides, I think Marcin was probably talki=
ng from the point of view of actual programming. A &quot;legal&quot; compil=
er could just as well replace the name of every variable with the output of=
 an MD5 hash, or place an extra kilobyte of padding between each pair of st=
ruct fields, but that doesn&#39;t mean that a hypothetical C++2x reflection=
 facility shouldn&#39;t expose things like variable names and struct layout=
s. Because the programmer might actually <i>want to use</i> reflection over=
 the names of their variables, or which attributes have been applied to a f=
unction, or struct layout, or whatever.</div><div><br></div><div>=E2=80=93A=
rthur</div></div></div></div></blockquote><div>Yes it would and I use legal=
 to express &quot;minimum required to be compliant&quot;.</div><div>By pars=
e-skip I meant that the declaration&#39;s internal representation is allowe=
d not to contain/save non-recognized attributes.<br></div><div>A compiler t=
hat would not-recognize &quot;noreturn&quot; for instance would still be co=
mpliant as the current standard defined attributes are allowed to be ignore=
d (their ill-form use as well).</div><div>A compiler that would hash into M=
D5 the variables name would clash explicitly with the reflection proposals.=
</div><div><br></div><div>My point was that completely ignoring unrecognize=
d attributes (which is compliant) can change the result of a computation wi=
th reflection:</div><div><br></div><div style=3D"background-color:rgb(250,2=
50,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px;w=
ord-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><sp=
an style=3D"color:#000"> A<br></span><span style=3D"color:#660">{</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#660">=
[[</span><span style=3D"color:#000">my_undefined_attribute</span><span styl=
e=3D"color:#660">]]</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">int</span><span style=3D"color:#000"> i</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#660">};</span><span style=3D"color:#000"><br><br></span><span style=3D"=
color:#008">for</span><span style=3D"color:#000"> </span><span style=3D"col=
or:#660">(</span><span style=3D"color:#008">auto</span><span style=3D"color=
:#000"> x </span><span style=3D"color:#660">:</span><span style=3D"color:#0=
00"> reflexpr</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">A</span><span style=3D"color:#660">).</span><span style=3D"color:#00=
0">member_variables</span><span style=3D"color:#660">()<wbr>)</span><span s=
tyle=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">if</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><=
span style=3D"color:#000">x</span><span style=3D"color:#660">.</span><span =
style=3D"color:#000">has_attribute</span><span style=3D"color:#660">(</span=
><span style=3D"color:#080">&quot;my_<wbr>undefined_attribute&quot;</span><=
span style=3D"color:#660">))</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0behaviour_a</span><span style=3D"color:#660">();</span>=
<span style=3D"color:#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#00=
8">else</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0beh=
aviour_b</span><span style=3D"color:#660">();</span><span style=3D"color:#0=
00"><br></span><span style=3D"color:#660">}</span></div></code></div></div>=
</blockquote><div>=C2=A0</div><div>Again: <br></div><div>&gt; IMHO &quot;ig=
nored&quot; in sens that they have no meaning for compiler not that they do=
 not exists</div><div> This is not statement about how it now behave but ho=
w it should behave.</div><div>When reflection hits then we can require for =
complying implementation that it store ALL attributes for reflection purpos=
es and nothing more.</div><div>They will be still &quot;ignored&quot; becau=
se will not affect any thing else in compiler.<br></div></div></blockquote>=
<div><br></div><div>Can you not see that, for the programmer, this is a dis=
tinction without a distinction? If something affects the standard-defined b=
ehavior of the program, the programmer doesn&#39;t care if it&#39;s the com=
piler doing it or some particular code that&#39;s causing that behavior. An=
d therefore, for the programmer, an attribute and a keyword are equally sig=
nificant.</div><div><br></div><div>Who cares if the &quot;compiler&quot; is=
 allowed to &quot;ignore&quot; it, when the compiler is<i> required</i> to =
pass that information along to other code which will not ignore it? That&#3=
9;s not ignoring it; that&#39;s not everything works as it did before.</div=
></div></blockquote><div>=C2=A0</div><div>This is why I use quotes in &quot=
;ignore&quot;. Overall this behavior what you describe is how I see attribu=
tes. As contract between programmers. Compiler can use it but is not requir=
ed. Programmer must obey it even if compiler do not implements it. We could=
 even name it as &quot;optional keywords&quot; because as you point out the=
y are for programmers equally significant.</div><div><br></div><div>Overall=
 attributes can create new dialects of C++ but if we keep rule that they al=
l can be &quot;ignored&quot; (quotes!) by compiler and behavior should be s=
ame then I could grab any compiler and any valid program and result will be=
 same. Even if it was written in some dialect of C++ crated by attributes.<=
/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/bb33d3d8-d2a3-4f8f-a4f9-eb221e5790ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bb33d3d8-d2a3-4f8f-a4f9-eb221e5790ea=
%40isocpp.org</a>.<br />

------=_Part_32653_878646439.1514738553902--

------=_Part_32652_823143596.1514738553902--

.

------=_Part_33806_655786026.1514765046090
Content-Type: multipart/alternative;
 boundary="----=_Part_33807_678325414.1514765046090"

------=_Part_33807_678325414.1514765046090
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sunday, December 31, 2017 at 11:42:33 AM UTC-5, Marcin Jaczewski wrote:

> On Sunday, December 31, 2017 at 5:21:18 PM UTC+1, Nicol Bolas wrote:
>>
>> On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski wrot=
e:
>>>
>>> On Sunday, December 31, 2017 at 7:11:08 AM UTC+1, bastie...@gmail.com=
=20
>>> wrote:
>>>>
>>>> On Sunday, December 31, 2017 at 1:38:02 AM UTC+1, Arthur O'Dwyer wrote=
:
>>>>>
>>>>> On Sat, Dec 30, 2017 at 4:05 PM, <bastie...@gmail.com> wrote:
>>>>>
>>>>>> On Saturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski=
=20
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> IMHO "ignored" in sens that they have no meaning for compiler not=
=20
>>>>>>> that they do not exists. Gathering attributes and write them to som=
e meta=20
>>>>>>> struct is not something that is hard to do and work with any attrib=
ute even=20
>>>>>>> if compiler have no clue what it mean. I think this fit attributes =
nicely.
>>>>>>>
>>>>>>
>>>>>> No actually, a compiler that would parse-skip c++ attributes would b=
e=20
>>>>>> legal.
>>>>>>
>>>>>
>>>>> Legal, sure, but obviously non-conforming. There are plenty of ways=
=20
>>>>> that [[attributes]] can render a translation unit "ill-formed, yes=20
>>>>> diagnostic required." A compiler that doesn't check for ill-formed=20
>>>>> constructs doesn't conform to the ISO standard... except perhaps in t=
he=20
>>>>> trivial sense that [intro.compliance] has no teeth. I'm pretty sure a=
=20
>>>>> conforming implementation could just output "?" in addition to its ma=
chine=20
>>>>> code and thus satisfy [intro.compliance].
>>>>>
>>>>> Besides, I think Marcin was probably talking from the point of view o=
f=20
>>>>> actual programming. A "legal" compiler could just as well replace the=
 name=20
>>>>> of every variable with the output of an MD5 hash, or place an extra=
=20
>>>>> kilobyte of padding between each pair of struct fields, but that does=
n't=20
>>>>> mean that a hypothetical C++2x reflection facility shouldn't expose t=
hings=20
>>>>> like variable names and struct layouts. Because the programmer might=
=20
>>>>> actually *want to use* reflection over the names of their variables,=
=20
>>>>> or which attributes have been applied to a function, or struct layout=
, or=20
>>>>> whatever.
>>>>>
>>>>> =E2=80=93Arthur
>>>>>
>>>> Yes it would and I use legal to express "minimum required to be=20
>>>> compliant".
>>>> By parse-skip I meant that the declaration's internal representation i=
s=20
>>>> allowed not to contain/save non-recognized attributes.
>>>> A compiler that would not-recognize "noreturn" for instance would stil=
l=20
>>>> be compliant as the current standard defined attributes are allowed to=
 be=20
>>>> ignored (their ill-form use as well).
>>>> A compiler that would hash into MD5 the variables name would clash=20
>>>> explicitly with the reflection proposals.
>>>>
>>>> My point was that completely ignoring unrecognized attributes (which i=
s=20
>>>> compliant) can change the result of a computation with reflection:
>>>>
>>>> struct A
>>>> {
>>>>    [[my_undefined_attribute]] int i;
>>>> };
>>>>
>>>> for (auto x : reflexpr(A).member_variables())
>>>> {
>>>>     if (x.has_attribute("my_undefined_attribute"))
>>>>        behaviour_a();
>>>>    else
>>>>        behaviour_b();
>>>> }
>>>>
>>> =20
>>> Again:=20
>>> > IMHO "ignored" in sens that they have no meaning for compiler not tha=
t=20
>>> they do not exists
>>> This is not statement about how it now behave but how it should behave.
>>> When reflection hits then we can require for complying implementation=
=20
>>> that it store ALL attributes for reflection purposes and nothing more.
>>> They will be still "ignored" because will not affect any thing else in=
=20
>>> compiler.
>>>
>>
>> Can you not see that, for the programmer, this is a distinction without =
a=20
>> distinction? If something affects the standard-defined behavior of the=
=20
>> program, the programmer doesn't care if it's the compiler doing it or so=
me=20
>> particular code that's causing that behavior. And therefore, for the=20
>> programmer, an attribute and a keyword are equally significant.
>>
>> Who cares if the "compiler" is allowed to "ignore" it, when the compiler=
=20
>> is* required* to pass that information along to other code which will=20
>> not ignore it? That's not ignoring it; that's not everything works as it=
=20
>> did before.
>>
> =20
> This is why I use quotes in "ignore".
>

And my point is that the "distinction"* does not matter* to actual users of=
=20
the language.

Overall this behavior what you describe is how I see attributes. As=20
> contract between programmers.
>

But attributes aren't used for communicating "between programmers".=20
[[no_unique_address]] doesn't exist to tell programmers something about the=
=20
subobject. It exists to tell the* compiler* something about what the=20
compiler can do with that subobject. [[noreturn]] and [[fallthrough]]=20
aren't some sort of documentation or contract among programmers; their=20
primary purpose is to tell the* compiler* to stop warning about some=20
situation.

There are too many attributes whose purpose exists beyond the scope of mere=
=20
documentation for your vision of attributes to match reality.

Compiler can use it but is not required. Programmer must obey it even if=20
> compiler do not implements it. We could even name it as "optional keyword=
s"=20
> because as you point out they are for programmers equally significant.
>
> Overall attributes can create new dialects of C++ but if we keep rule tha=
t=20
> they all can be "ignored" (quotes!) by compiler and behavior should be sa=
me=20
> then I could grab any compiler and any valid program and result will be=
=20
> same. Even if it was written in some dialect of C++ crated by attributes.
>
>

--=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/276ada1f-1f77-47bf-95f5-5133f23155bd%40isocpp.or=
g.

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

<div dir=3D"ltr">On Sunday, December 31, 2017 at 11:42:33 AM UTC-5, Marcin =
Jaczewski wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Sunday, December 31, 2017 at 5:21:18 PM UTC+1, Nicol Bolas wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, Decem=
ber 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Sunday, December 31, 2017 at 7:1=
1:08 AM UTC+1, <a>bastie...@gmail.com</a> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr">On Sunday, December 31, 2017 at 1:38:02 AM UT=
C+1, Arthur O&#39;Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr">On Sat, Dec 30, 2017 at 4:05 PM,  <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">bastie...@gmail.com</a>&gt;</span> wrote:<br><div><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On S=
aturday, December 30, 2017 at 7:06:19 PM UTC+1, Marcin Jaczewski wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>IM=
HO &quot;ignored&quot; in sens that they have no meaning for compiler not t=
hat they do not exists. Gathering attributes and write them to some meta st=
ruct is not something that is hard to do and work with any attribute even i=
f compiler have no clue what it mean. I think this fit attributes nicely.</=
div></div></blockquote><div><br></div></span><div>No actually, a compiler t=
hat would parse-skip c++ attributes would be legal.</div></div></blockquote=
><div><br></div><div>Legal, sure, but obviously non-conforming. There are p=
lenty of ways that [[attributes]] can render a translation unit &quot;ill-f=
ormed, yes diagnostic required.&quot; A compiler that doesn&#39;t check for=
 ill-formed constructs doesn&#39;t conform to the ISO standard... except pe=
rhaps in the trivial sense that [intro.compliance] has no teeth. I&#39;m pr=
etty sure a conforming implementation could just output &quot;?&quot; in ad=
dition to its machine code and thus satisfy [intro.compliance].</div><div><=
br></div><div>Besides, I think Marcin was probably talking from the point o=
f view of actual programming. A &quot;legal&quot; compiler could just as we=
ll replace the name of every variable with the output of an MD5 hash, or pl=
ace an extra kilobyte of padding between each pair of struct fields, but th=
at doesn&#39;t mean that a hypothetical C++2x reflection facility shouldn&#=
39;t expose things like variable names and struct layouts. Because the prog=
rammer might actually <i>want to use</i> reflection over the names of their=
 variables, or which attributes have been applied to a function, or struct =
layout, or whatever.</div><div><br></div><div>=E2=80=93Arthur</div></div></=
div></div></blockquote><div>Yes it would and I use legal to express &quot;m=
inimum required to be compliant&quot;.</div><div>By parse-skip I meant that=
 the declaration&#39;s internal representation is allowed not to contain/sa=
ve non-recognized attributes.<br></div><div>A compiler that would not-recog=
nize &quot;noreturn&quot; for instance would still be compliant as the curr=
ent standard defined attributes are allowed to be ignored (their ill-form u=
se as well).</div><div>A compiler that would hash into MD5 the variables na=
me would clash explicitly with the reflection proposals.</div><div><br></di=
v><div>My point was that completely ignoring unrecognized attributes (which=
 is compliant) can change the result of a computation with reflection:</div=
><div><br></div><div style=3D"background-color:rgb(250,250,250);border-colo=
r:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word=
"><code><div><span style=3D"color:#008">struct</span><span style=3D"color:#=
000"> A<br></span><span style=3D"color:#660">{</span><span style=3D"color:#=
000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#660">[[</span><span styl=
e=3D"color:#000">my_undefined_attribute</span><span style=3D"color:#660">]]=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</s=
pan><span style=3D"color:#000"> i</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><=
span style=3D"color:#000"><br><br></span><span style=3D"color:#008">for</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#008">auto</span><span style=3D"color:#000"> x </span><s=
pan style=3D"color:#660">:</span><span style=3D"color:#000"> reflexpr</span=
><span style=3D"color:#660">(</span><span style=3D"color:#000">A</span><spa=
n style=3D"color:#660">).</span><span style=3D"color:#000">member_variables=
</span><span style=3D"color:#660">()<wbr>)</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">if</span><span style=3D"=
color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">x</span><span style=3D"color:#660">.</span><span style=3D"color:#000=
">has_attribute</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#080">&quot;my_<wbr>undefined_attribute&quot;</span><span style=3D"color=
:#660">))</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0b=
ehaviour_a</span><span style=3D"color:#660">();</span><span style=3D"color:=
#000"><br>=C2=A0 =C2=A0</span><span style=3D"color:#008">else</span><span s=
tyle=3D"color:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0behaviour_b</span><span =
style=3D"color:#660">();</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">}</span></div></code></div></div></blockquote><div>=C2=
=A0</div><div>Again: <br></div><div>&gt; IMHO &quot;ignored&quot; in sens t=
hat they have no meaning for compiler not that they do not exists</div><div=
> This is not statement about how it now behave but how it should behave.</=
div><div>When reflection hits then we can require for complying implementat=
ion that it store ALL attributes for reflection purposes and nothing more.<=
/div><div>They will be still &quot;ignored&quot; because will not affect an=
y thing else in compiler.<br></div></div></blockquote><div><br></div><div>C=
an you not see that, for the programmer, this is a distinction without a di=
stinction? If something affects the standard-defined behavior of the progra=
m, the programmer doesn&#39;t care if it&#39;s the compiler doing it or som=
e particular code that&#39;s causing that behavior. And therefore, for the =
programmer, an attribute and a keyword are equally significant.</div><div><=
br></div><div>Who cares if the &quot;compiler&quot; is allowed to &quot;ign=
ore&quot; it, when the compiler is<i> required</i> to pass that information=
 along to other code which will not ignore it? That&#39;s not ignoring it; =
that&#39;s not everything works as it did before.</div></div></blockquote><=
div>=C2=A0</div><div>This is why I use quotes in &quot;ignore&quot;.</div><=
/div></blockquote><div><br></div><div>And my point is that the &quot;distin=
ction&quot;<i> does not matter</i> to actual users of the language.</div><d=
iv><i><br></i></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Overall this behavior what you describe is how I see attribut=
es. As contract between programmers.</div></div></blockquote><div><br></div=
><div>But attributes aren&#39;t used for communicating &quot;between progra=
mmers&quot;. [[no_unique_address]] doesn&#39;t exist to tell programmers so=
mething about the subobject. It exists to tell the<i> compiler</i> somethin=
g about what the compiler can do with that subobject. [[noreturn]] and [[fa=
llthrough]] aren&#39;t some sort of documentation or contract among program=
mers; their primary purpose is to tell the<i> compiler</i> to stop warning =
about some situation.</div><div><br></div><div>There are too many attribute=
s whose purpose exists beyond the scope of mere documentation for your visi=
on of attributes to match reality.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div>Compiler can use it but is n=
ot required. Programmer must obey it even if compiler do not implements it.=
 We could even name it as &quot;optional keywords&quot; because as you poin=
t out they are for programmers equally significant.</div><div><br></div><di=
v>Overall attributes can create new dialects of C++ but if we keep rule tha=
t they all can be &quot;ignored&quot; (quotes!) by compiler and behavior sh=
ould be same then I could grab any compiler and any valid program and resul=
t will be same. Even if it was written in some dialect of C++ crated by att=
ributes.</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/276ada1f-1f77-47bf-95f5-5133f23155bd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/276ada1f-1f77-47bf-95f5-5133f23155bd=
%40isocpp.org</a>.<br />

------=_Part_33807_678325414.1514765046090--

------=_Part_33806_655786026.1514765046090--

.

------=_Part_34413_1886741301.1514775848208
Content-Type: multipart/alternative;
 boundary="----=_Part_34414_58979968.1514775848208"

------=_Part_34414_58979968.1514775848208
Content-Type: text/plain; charset="UTF-8"



On Monday, January 1, 2018 at 1:04:06 AM UTC+1, Nicol Bolas wrote:
>
> On Sunday, December 31, 2017 at 11:42:33 AM UTC-5, Marcin Jaczewski wrote:
>
>> On Sunday, December 31, 2017 at 5:21:18 PM UTC+1, Nicol Bolas wrote:
>>>
>>> On Sunday, December 31, 2017 at 10:58:58 AM UTC-5, Marcin Jaczewski
>>> wrote:
>>>
>>> Can you not see that, for the programmer, this is a distinction without
>>> a distinction? If something affects the standard-defined behavior of the
>>> program, the programmer doesn't care if it's the compiler doing it or some
>>> particular code that's causing that behavior. And therefore, for the
>>> programmer, an attribute and a keyword are equally significant.
>>>
>>> Who cares if the "compiler" is allowed to "ignore" it, when the compiler
>>> is* required* to pass that information along to other code which will
>>> not ignore it? That's not ignoring it; that's not everything works as it
>>> did before.
>>>
>>
>> This is why I use quotes in "ignore".
>>
>
> And my point is that the "distinction"* does not matter* to actual users
> of the language.
>
> Overall this behavior what you describe is how I see attributes. As
>> contract between programmers.
>>
>
> But attributes aren't used for communicating "between programmers".
> [[no_unique_address]] doesn't exist to tell programmers something about the
> subobject. It exists to tell the* compiler* something about what the
> compiler can do with that subobject. [[noreturn]] and [[fallthrough]]
> aren't some sort of documentation or contract among programmers; their
> primary purpose is to tell the* compiler* to stop warning about some
> situation.
>
> There are too many attributes whose purpose exists beyond the scope of
> mere documentation for your vision of attributes to match reality.
>
>
No, no, not documentation, custom behavior and rules that can be check/used
by external programs, in special case by compiler. And again I'm not
speaking about what attributes are right now but what direction should they
go. They could be used too to change implementation defined behavior (or at
least ask for some specific implementation).

--
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/7f079420-caf1-4101-9cc6-a1c2cf08b98e%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Monday, January 1, 2018 at 1:04:06 AM UTC+1, Ni=
col 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"lt=
r">On Sunday, December 31, 2017 at 11:42:33 AM UTC-5, Marcin Jaczewski wrot=
e:<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">On Sunday, D=
ecember 31, 2017 at 5:21:18 PM UTC+1, Nicol Bolas wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">On Sunday, December 31, 2017 at 10:=
58:58 AM UTC-5, Marcin Jaczewski wrote:<div><br></div><div>Can you not see =
that, for the programmer, this is a distinction without a distinction? If s=
omething affects the standard-defined behavior of the program, the programm=
er doesn&#39;t care if it&#39;s the compiler doing it or some particular co=
de that&#39;s causing that behavior. And therefore, for the programmer, an =
attribute and a keyword are equally significant.</div><div><br></div><div>W=
ho cares if the &quot;compiler&quot; is allowed to &quot;ignore&quot; it, w=
hen the compiler is<i> required</i> to pass that information along to other=
 code which will not ignore it? That&#39;s not ignoring it; that&#39;s not =
everything works as it did before.</div></div></blockquote><div>=C2=A0</div=
><div>This is why I use quotes in &quot;ignore&quot;.</div></div></blockquo=
te><div><br></div><div>And my point is that the &quot;distinction&quot;<i> =
does not matter</i> to actual users of the language.</div><div><i><br></i><=
/div><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>Overall =
this behavior what you describe is how I see attributes. As contract betwee=
n programmers.</div></div></blockquote><div><br></div><div>But attributes a=
ren&#39;t used for communicating &quot;between programmers&quot;. [[no_uniq=
ue_address]] doesn&#39;t exist to tell programmers something about the subo=
bject. It exists to tell the<i> compiler</i> something about what the compi=
ler can do with that subobject. [[noreturn]] and [[fallthrough]] aren&#39;t=
 some sort of documentation or contract among programmers; their primary pu=
rpose is to tell the<i> compiler</i> to stop warning about some situation.<=
/div><div><br></div></div></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div></div><div>There are too many attributes who=
se purpose exists beyond the scope of mere documentation for your vision of=
 attributes to match reality.</div><br></div></blockquote><div><br></div><d=
iv>No, no, not documentation, custom behavior and rules that can be check/u=
sed by external programs, in special case by compiler. And again I&#39;m no=
t speaking about what attributes are right now but what direction should th=
ey go. They could be used too to change implementation defined behavior (or=
 at least ask for some specific implementation).<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/7f079420-caf1-4101-9cc6-a1c2cf08b98e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7f079420-caf1-4101-9cc6-a1c2cf08b98e=
%40isocpp.org</a>.<br />

------=_Part_34414_58979968.1514775848208--

------=_Part_34413_1886741301.1514775848208--

.