------=_Part_21987_2133231264.1514398535331
Content-Type: multipart/alternative;
 boundary="----=_Part_21988_2132661516.1514398535332"

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

There is clearly intended to be a dividing line between C++ attributes and=
=20
C++ keywords.

Herb Sutter outlined one version of this division=20
<https://herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/>. As=
=20
he states:

> [[attributes]] are specifically designed to be ignorable and shouldn=E2=
=80=99t be=20
used for things having language semantic meaning.

P0840 <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0840r0.html=
>=20
offers a different but similar division:

> compiling a valid program with all instances of a particular attribute=20
ignored must result in a correct interpretation of the original program

I submit that these dividing lines are both unsustainable and *have already=
=20
been violated*.

Consider [[fallthrough]]. We use this attribute in `switch/case`=20
statements, to represent a place where fallthrough is intended. This allows=
=20
us to turn on compiler warnings/errors about fallthrough; the explicit use=
=20
of the attribute lets us know that we're falling through intentionally.

What makes this unsustainable is this: what we eventually want to do is=20
make [[fallthrough]]* mandatory*. That is, to make it ill-formed to fall=20
through without explicitly asking for it. The problem is that we can't. So=
=20
long as we stick to the above rules about attributes, we cannot have the=20
standard declare the lack of use of an attribute to be ill-formed.

This is precisely why `final` and `override` are keywords rather than=20
attributes: because we wanted to make it ill-formed.

Something similar happens with [[noreturn]]: if we ever want to make=20
functions that fail to return ill-formed, we would have to make such a rule=
=20
take into account calls to [[noreturn]] functions. But we can't do that,=20
because attributes cannot be used to make something ill-formed.

As for previously violated... well, P0840 fits that bill rather nicely. It=
=20
was forwarded to CWG, despite its attribute violating the very principle it=
=20
outlines. How? Well, that's easy: `is_empty` changes.

Oh, it changes based on implementations. But the big point is that it=20
changes based on whether the attribute is ignored or not. A class with=20
empty members not declared with [[no_unique_address]] is never empty. But a=
=20
class with empty members declared with that attribute may be empty. That=20
changes visible behavior, which can result in an incorrect interpretation=
=20
of the code without that attribute.

That's not to say that we shouldn't have* some* distinction between=20
keywords and attributes. But the current distinction is not really=20
functional at present. There are too many exceptions and desired exceptions=
=20
to pretend that such things are not genuine parts of C++ grammar.

What would a better distinction look like? I would say that something=20
should be an attribute if it is:

1) A property that indicates, clarifies, or tweaks a specific aspect of the=
=20
program, but not in a way that is truly fundamental to its behavior.=20
`co_await` changes control flow, so it's not an attribute. [[noreturn]]=20
doesn't really *change* control flow; whether the function returns or not=
=20
is part of its implementation. The attribute is just an indicator to the=20
caller about its behavior.
2) Something which would be useful to preemptively apply to versions of C++=
=20
that don't support that feature yet. That is, would it be reasonable to=20
start shoving that property at compilers that compile older code?

But we should not separate out attributes from keywords in terms of their=
=20
relation to overall program behavior. That is, we should ditch the idea=20
that attributes should be considered "ignorable", that the lack of an=20
attribute should never cause a program to be ill-formed.

--=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/86919454-9af9-4b08-b7b3-fd262b46cdd5%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>There is clearly intended to be a dividing line betwe=
en C++ attributes and C++ keywords.</div><div><br></div><div>Herb Sutter <a=
 href=3D"https://herbsutter.com/2012/04/02/reader-qa-keywords-and-attribute=
s/">outlined one version of this division</a>. As he states:</div><div><br>=
</div><div>&gt;=C2=A0[[attributes]] are specifically designed to be ignorab=
le and shouldn=E2=80=99t be used for things having language semantic meanin=
g.</div><div><br></div><div><a href=3D"http://www.open-std.org/JTC1/SC22/WG=
21/docs/papers/2017/p0840r0.html">P0840</a> offers a different but similar =
division:</div><div><br></div><div>&gt;=C2=A0compiling a valid program with=
 all instances of a particular attribute ignored
must result in a correct interpretation of the original program</div><div><=
br></div><div>I submit that these dividing lines are both unsustainable and=
 <i>have already been violated</i>.</div><div><br></div><div>Consider [[fal=
lthrough]]. We use this attribute in `switch/case` statements, to represent=
 a place where fallthrough is intended. This allows us to turn on compiler =
warnings/errors about fallthrough; the explicit use of the attribute lets u=
s know that we&#39;re falling through intentionally.</div><div><br></div><d=
iv>What makes this unsustainable is this: what we eventually want to do is =
make [[fallthrough]]<i> mandatory</i>. That is, to make it ill-formed to fa=
ll through without explicitly asking for it. The problem is that we can&#39=
;t. So long as we stick to the above rules about attributes, we cannot have=
 the standard declare the lack of use of an attribute to be ill-formed.</di=
v><div><br></div><div>This is precisely why `final` and `override` are keyw=
ords rather than attributes: because we wanted to make it ill-formed.</div>=
<div><br></div><div>Something similar happens with [[noreturn]]: if we ever=
 want to make functions that fail to return ill-formed, we would have to ma=
ke such a rule take into account calls to [[noreturn]] functions. But we ca=
n&#39;t do that, because attributes cannot be used to make something ill-fo=
rmed.</div><div><br></div><div>As for previously violated... well, P0840 fi=
ts that bill rather nicely. It was forwarded to CWG, despite its attribute =
violating the very principle it outlines. How? Well, that&#39;s easy: `is_e=
mpty` changes.</div><div><br></div><div>Oh, it changes based on implementat=
ions. But the big point is that it changes based on whether the attribute i=
s ignored or not. A class with empty members not declared with [[no_unique_=
address]] is never empty. But a class with empty members declared with that=
 attribute may be empty. That changes visible behavior, which can result in=
 an incorrect interpretation of the code without that attribute.</div><div>=
<br></div><div>That&#39;s not to say that we shouldn&#39;t have<i> some</i>=
 distinction between keywords and attributes. But the current distinction i=
s not really functional at present. There are too many exceptions and desir=
ed exceptions to pretend that such things are not genuine parts of C++ gram=
mar.</div><div><br></div><div>What would a better distinction look like? I =
would say that something should be an attribute if it is:</div><div><br></d=
iv><div>1) A property that indicates, clarifies, or tweaks a specific aspec=
t of the program, but not in a way that is truly fundamental to its behavio=
r. `co_await` changes control flow, so it&#39;s not an attribute. [[noretur=
n]] doesn&#39;t really <i>change</i> control flow; whether the function ret=
urns or not is part of its implementation. The attribute is just an indicat=
or to the caller about its behavior.</div><div>2) Something which would be =
useful to preemptively apply to versions of C++ that don&#39;t support that=
 feature yet. That is, would it be reasonable to start shoving that propert=
y at compilers that compile older code?</div><div><br></div><div>But we sho=
uld not separate out attributes from keywords in terms of their relation to=
 overall program behavior. That is, we should ditch the idea that attribute=
s should be considered &quot;ignorable&quot;, that the lack of an attribute=
 should never cause a program to be ill-formed.</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/86919454-9af9-4b08-b7b3-fd262b46cdd5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/86919454-9af9-4b08-b7b3-fd262b46cdd5=
%40isocpp.org</a>.<br />

------=_Part_21988_2132661516.1514398535332--

------=_Part_21987_2133231264.1514398535331--

.

------=_Part_21781_966120433.1514403853706
Content-Type: multipart/alternative;
 boundary="----=_Part_21782_2047031913.1514403853706"

------=_Part_21782_2047031913.1514403853706
Content-Type: text/plain; charset="UTF-8"

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.

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

<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 ar=
e right -=C2=A0[[no_unique_address]], on and off, creates two different pro=
grams, granted both well-formed, but different never the less.</div><div><b=
r></div><div>All other attributes so far fall into only two categories - co=
mmunication with the user (more errors and warnings) and turning off synchr=
onizations. </div><div>In neither case the program is observably (as in sta=
tic checks, not performance) different.=C2=A0</div><div><br></div><div>I do=
n&#39;t know how to feel about it. Never ever though about attributes as ig=
norable. Ever. </div><div>Especially before standardization when people wen=
t to great lengths to add an attribute for every compiler and every platfor=
m precisely because their program depended on it.</div><div>Sometimes vital=
ly (like in &quot;it will crash in minutes otherwise&quot;).=C2=A0</div><di=
v><br></div><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/40edf1b5-5c72-4682-902e-1c0cea581e37%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/40edf1b5-5c72-4682-902e-1c0cea581e37=
%40isocpp.org</a>.<br />

------=_Part_21782_2047031913.1514403853706--

------=_Part_21781_966120433.1514403853706--

.

------=_Part_17782_1456175466.1514414251976
Content-Type: multipart/alternative;
 boundary="----=_Part_17783_967905290.1514414251976"

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

On Wednesday, December 27, 2017 at 10:15:35 AM UTC-8, Nicol Bolas wrote:
>
> There is clearly intended to be a dividing line between C++ attributes an=
d=20
> C++ keywords.
>
> Herb Sutter outlined one version of this division=20
> <https://herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/>.=
=20
> As he states:
>
> > [[attributes]] are specifically designed to be ignorable and shouldn=E2=
=80=99t=20
> be used for things having language semantic meaning.
>
> P0840=20
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0840r0.html>=20
> offers a different but similar division:
>
> > compiling a valid program with all instances of a particular attribute=
=20
> ignored must result in a correct interpretation of the original program
>
> I submit that these dividing lines are both unsustainable and *have=20
> already been violated*.
>

I submit that the current situation is fine. We have guidelines, and we=20
have smart people in charge of making sure that reality follows those=20
guidelines as closely as possible (but no closer).

The original source of the "Attributes should not change semantics"=20
guideline was N2761 "Towards support for attributes in C++ (R6)", in 2008.=
=20
Here is the complete text of the guidelines at the time, with hyperlinks to=
=20
various original documents, which I collated the last time this topic came=
=20
up.
https://groups.google.com/a/isocpp.org/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ
IMO, these guidelines have held up very well.  They are still quite=20
sensible.  I don't think N2761 has any embarrassing conflicts with the=20
actual history of C++ since 2008.


What makes this unsustainable is this: what we eventually want to do is=20
> make [[fallthrough]]* mandatory*. That is, to make it ill-formed to fall=
=20
> through without explicitly asking for it. The problem is that we can't. S=
o=20
> long as we stick to the above rules about attributes, we cannot have the=
=20
> standard declare the lack of use of an attribute to be ill-formed.
>

I think you're mixing senses of the word "we".  *Individual programmers*=20
may want to make [[fallthrough]] mandatory or may not, depending on their=
=20
degree of paranoia and/or degree of spending time maintaining C code from=
=20
the 1980s.  *Individual vendors* are effectively free to make=20
[[fallthrough]] mandatory today (and have generally already done so, in the=
=20
recommended -W -Wall -Werror mode of invocation).  *The ISO C++ Committee*=
=20
indeed cannot declare the lack of use of an attribute to be ill-formed, as=
=20
long as the ISO C++ Committee sticks (strictly) to the above guidelines;=20
but fortunately, I don't think the ISO C++ Committee has much interest in=
=20
sticking strictly to any guideline ever.  Heck, they don't even stick to=20
the *official ISO language standard* for more than three years at a time=20
anymore. ;)


Something similar happens with [[noreturn]]: if we ever want to make=20
> functions that fail to return ill-formed, we would have to make such a ru=
le=20
> take into account calls to [[noreturn]] functions. But we can't do that,=
=20
> because attributes cannot be used to make something ill-formed.
>

As observed in many a previous thread: sure they can. Look at=20
[dcl.attr.fallthrough]/1, specifically the sentence beginning "The program=
=20
is ill-formed if..."
The Committee follows its self-imposed guidelines *as closely as possible,=
=20
but no closer*.

[...]

> But we should not separate out attributes from keywords in terms of their=
=20
> relation to overall program behavior. That is, we should ditch the idea=
=20
> that attributes should be considered "ignorable", that the lack of an=20
> attribute should never cause a program to be ill-formed.
>

I have good news for you. ;)

=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/b46ccd49-43c8-424e-90c9-3053128f6560%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, December 27, 2017 at 10:15:35 AM UTC-8, Nico=
l Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>There is clearly intended to be a dividing line between C++ attribute=
s and C++ keywords.</div><div><br></div><div>Herb Sutter <a href=3D"https:/=
/herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fherbsutter.com%2F2012%2F04%2F02%2Freader-qa-keywo=
rds-and-attributes%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbFG4_kMN2lB4=
sho01UUyGR606Yg&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fherbsutter.com%2F2012%2F04%2F02%2Freader-=
qa-keywords-and-attributes%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbFG4=
_kMN2lB4sho01UUyGR606Yg&#39;;return true;">outlined one version of this div=
ision</a>. As he states:</div><div><br></div><div>&gt;=C2=A0[[attributes]] =
are specifically designed to be ignorable and shouldn=E2=80=99t be used for=
 things having language semantic meaning.</div><div><br></div><div><a href=
=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0840r0.html" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://ww=
w.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2F=
docs%2Fpapers%2F2017%2Fp0840r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NErg6DrPIy-NrUzpoBnQvvMw_DJfg&#39;;return true;" onclick=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC2=
2%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0840r0.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNErg6DrPIy-NrUzpoBnQvvMw_DJfg&#39;;return true;">P0840</a> offer=
s a different but similar division:</div><div><br></div><div>&gt;=C2=A0comp=
iling a valid program with all instances of a particular attribute ignored
must result in a correct interpretation of the original program</div><div><=
br></div><div>I submit that these dividing lines are both unsustainable and=
 <i>have already been violated</i>.</div></div></blockquote><div><br></div>=
<div>I submit that the current situation is fine. We have guidelines, and w=
e have smart people in charge of making sure that reality follows those gui=
delines as closely as possible (but no closer).</div><div><br></div><div>Th=
e original source of the &quot;Attributes should not change semantics&quot;=
 guideline was N2761 &quot;Towards support for attributes in C++ (R6)&quot;=
, in 2008. Here is the complete text of the guidelines at the time, with hy=
perlinks to various original documents, which I collated the last time this=
 topic came up.</div><div><a href=3D"https://groups.google.com/a/isocpp.org=
/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ">https://groups.google.com/a/isocpp.or=
g/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ</a><br></div><div>IMO, these guidelin=
es have held up very well. =C2=A0They are still quite sensible. =C2=A0I don=
&#39;t think N2761 has any embarrassing conflicts with the actual history o=
f C++ since 2008.</div><div><br></div><div><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div>What makes this unsustainable =
is this: what we eventually want to do is make [[fallthrough]]<i> mandatory=
</i>. That is, to make it ill-formed to fall through without explicitly ask=
ing for it. The problem is that we can&#39;t. So long as we stick to the ab=
ove rules about attributes, we cannot have the standard declare the lack of=
 use of an attribute to be ill-formed.<br></div></div></blockquote><div><br=
></div><div>I think you&#39;re mixing senses of the word &quot;we&quot;.=C2=
=A0=C2=A0<b>Individual programmers</b> may want to make [[fallthrough]] man=
datory or may not, depending on their degree of paranoia and/or degree of s=
pending time maintaining C code from the 1980s.=C2=A0=C2=A0<b>Individual ve=
ndors</b>=C2=A0are effectively free to make [[fallthrough]] mandatory today=
 (and have generally already done so, in the recommended -W -Wall -Werror m=
ode of invocation). =C2=A0<b>The ISO C++ Committee</b> indeed cannot declar=
e the lack of use of an attribute to be ill-formed, as long as the ISO C++ =
Committee sticks (strictly) to the above guidelines; but fortunately, I don=
&#39;t think the ISO C++ Committee has much interest in sticking strictly t=
o any guideline ever. =C2=A0Heck, they don&#39;t even stick to the <i>offic=
ial ISO language standard</i> for more than three years at a time anymore. =
;)</div><div><br></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div></div><div>Something similar happens with [[n=
oreturn]]: if we ever want to make functions that fail to return ill-formed=
, we would have to make such a rule take into account calls to [[noreturn]]=
 functions. But we can&#39;t do that, because attributes cannot be used to =
make something ill-formed.</div></div></blockquote><div><br></div><div>As o=
bserved in many a previous thread: sure they can. Look at [dcl.attr.fallthr=
ough]/1, specifically the sentence beginning &quot;The program is ill-forme=
d if...&quot;</div><div>The Committee follows its self-imposed guidelines <=
i>as closely as possible, but no closer</i>.</div><div><br></div><div>[...]=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Bu=
t we should not separate out attributes from keywords in terms of their rel=
ation to overall program behavior. That is, we should ditch the idea that a=
ttributes should be considered &quot;ignorable&quot;, that the lack of an a=
ttribute should never cause a program to be ill-formed.<br></div></div></bl=
ockquote><div><br></div><div>I have good news for you. ;)</div><div><br></d=
iv><div>=E2=80=93Arthur</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/b46ccd49-43c8-424e-90c9-3053128f6560%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b46ccd49-43c8-424e-90c9-3053128f6560=
%40isocpp.org</a>.<br />

------=_Part_17783_967905290.1514414251976--

------=_Part_17782_1456175466.1514414251976--

.

------=_Part_22802_1952846971.1514425690416
Content-Type: multipart/alternative;
 boundary="----=_Part_22803_1427533715.1514425690417"

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

On Wednesday, December 27, 2017 at 5:37:32 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Wednesday, December 27, 2017 at 10:15:35 AM UTC-8, Nicol Bolas wrote:
>>
>> There is clearly intended to be a dividing line between C++ attributes=
=20
>> and C++ keywords.
>>
>> Herb Sutter outlined one version of this division=20
>> <https://herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/>.=
=20
>> As he states:
>>
>> > [[attributes]] are specifically designed to be ignorable and shouldn=
=E2=80=99t=20
>> be used for things having language semantic meaning.
>>
>> P0840=20
>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0840r0.html>=
=20
>> offers a different but similar division:
>>
>> > compiling a valid program with all instances of a particular attribute=
=20
>> ignored must result in a correct interpretation of the original program
>>
>> I submit that these dividing lines are both unsustainable and *have=20
>> already been violated*.
>>
>
> I submit that the current situation is fine. We have guidelines, and we=
=20
> have smart people in charge of making sure that reality follows those=20
> guidelines as closely as possible (but no closer).
>
> The original source of the "Attributes should not change semantics"=20
> guideline was N2761 "Towards support for attributes in C++ (R6)", in 2008=
..=20
> Here is the complete text of the guidelines at the time, with hyperlinks =
to=20
> various original documents, which I collated the last time this topic cam=
e=20
> up.
> https://groups.google.com/a/isocpp.org/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQA=
J
> IMO, these guidelines have held up very well.  They are still quite=20
> sensible.  I don't think N2761 has any embarrassing conflicts with the=20
> actual history of C++ since 2008.
>

Are we reading the same N2761?

Under "Good choices in attributes include:", they list "final". Which was=
=20
explicitly changed to be a contextual keyword. The same goes with=20
"not_hiding", except that this was discarded entirely. And it says that=20
`align` would be a good attribute, and it most assuredly is a keyword=20
(though grammatically, it does go in the attribute section).

When you recommend that one thing would make a good attribute, and then=20
everyone decides explicitly not to make it an attribute, I would call that=
=20
an "embarrassing conflict". When it happens* three times*, I'd call it=20
"nobody's listening to you" ;)

Also, let us consider the advice on when *not* to make something an=20
attribute, and compare it to P0840:

** The feature is used in expressions as opposed to declarations.*

Check: [[no_unique_address]] is used on declarations.

** The feature is of use to a broad audience.*

You can argue that [[no_unique_address]] is of limited use, but I very=20
strongly disagree with this.* Every* C++ programmer should have this tool=
=20
in their toolbox. It comes up very often as a basic point of optimization.

** The feature is a central part of the declaration that significantly=20
affects its requirements/semantics (e.g., constexpr).*

Again, you can argue that [[no_unqiue_address]] doesn't "significantly"=20
affect "semantics", but I disagree. If it wasn't going to affect the=20
behavior of the program, you* wouldn't use it*.

** The feature modifies the type system and/or overload resolution in a=20
significant way (e.g., rvalue references).*  (However, something like near=
=20
and far pointers should probably still be handled by attributes, although=
=20
those do affect the type system.)

Check; this doesn't modify the type system. Though I find the parenthetical=
=20
to be essentially an admission that these guidelines are not really taken=
=20
seriously.

** The feature is used everywhere on every instance of class, or statements=
*

It's not going to be *that* widely used. But honestly, I think it'll be=20
used more than people expect. Once people have a no-cost way of invoking=20
this optimization, people will use it. I mean really, why* wouldn't* you=20
use it whenever you're given a template argument type which you're going to=
=20
make a member subobject, but you only need one of them? It's not so much=20
that you're expecting a gain, but... why throw away the possibility?

So by N2761's guidelines, [[no_unique_address]] should be a keyword, not an=
=20
attribute. By Herb's general rule, it should be a keyword. By P0840's own=
=20
rules, it should be a keyword.

Yet it is an attribute.

How exactly is the committee keeping to these guidelines?

What makes this unsustainable is this: what we eventually want to do is=20
>> make [[fallthrough]]* mandatory*. That is, to make it ill-formed to fall=
=20
>> through without explicitly asking for it. The problem is that we can't. =
So=20
>> long as we stick to the above rules about attributes, we cannot have the=
=20
>> standard declare the lack of use of an attribute to be ill-formed.
>>
>
> I think you're mixing senses of the word "we".  *Individual programmers*=
=20
> may want to make [[fallthrough]] mandatory or may not, depending on their=
=20
> degree of paranoia and/or degree of spending time maintaining C code from=
=20
> the 1980s.  *Individual vendors* are effectively free to make=20
> [[fallthrough]] mandatory today (and have generally already done so, in t=
he=20
> recommended -W -Wall -Werror mode of invocation).  *The ISO C++ Committee=
*=20
> indeed cannot declare the lack of use of an attribute to be ill-formed, a=
s=20
> long as the ISO C++ Committee sticks (strictly) to the above guidelines;=
=20
> but fortunately, I don't think the ISO C++ Committee has much interest in=
=20
> sticking strictly to any guideline ever.  Heck, they don't even stick to=
=20
> the *official ISO language standard* for more than three years at a time=
=20
> anymore. ;)
>

If the committee doesn't follow its own guidelines, why have the guideline=
=20
at all? Why not just openly declare, "hey, attributes really are just a way=
=20
to get a low-cost keyword into the language." If you ignore a rule whenever=
=20
it is convenient for you, then why have it?

Rules that aren't followed are not rules.

--=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/094e32b8-2d97-43b0-a472-0e96752cd293%40isocpp.or=
g.

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

<div dir=3D"ltr">On Wednesday, December 27, 2017 at 5:37:32 PM UTC-5, Arthu=
r 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"ltr">On Wednesday, December 27, 2017 at 10:15:35 AM UTC-8, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There i=
s clearly intended to be a dividing line between C++ attributes and C++ key=
words.</div><div><br></div><div>Herb Sutter <a onmousedown=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fherbsutter.com%2F2012%2F0=
4%2F02%2Freader-qa-keywords-and-attributes%2F\x26sa\x3dD\x26sntz\x3d1\x26us=
g\x3dAFQjCNGbFG4_kMN2lB4sho01UUyGR606Yg&#39;;return true;" onclick=3D"this.=
href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fherbsutter.com%2F=
2012%2F04%2F02%2Freader-qa-keywords-and-attributes%2F\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNGbFG4_kMN2lB4sho01UUyGR606Yg&#39;;return true;" href=3D"=
https://herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/" targe=
t=3D"_blank" rel=3D"nofollow">outlined one version of this division</a>. As=
 he states:</div><div><br></div><div>&gt;=C2=A0[[attributes]] are specifica=
lly designed to be ignorable and shouldn=E2=80=99t be used for things havin=
g language semantic meaning.</div><div><br></div><div><a onmousedown=3D"thi=
s.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%=
2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0840r0.html\x26sa\x3dD\x26sn=
tz\x3d1\x26usg\x3dAFQjCNErg6DrPIy-NrUzpoBnQvvMw_DJfg&#39;;return true;" onc=
lick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.op=
en-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0840r0.html\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErg6DrPIy-NrUzpoBnQvvMw_DJfg&#39;;return=
 true;" href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p08=
40r0.html" target=3D"_blank" rel=3D"nofollow">P0840</a> offers a different =
but similar division:</div><div><br></div><div>&gt;=C2=A0compiling a valid =
program with all instances of a particular attribute ignored
must result in a correct interpretation of the original program</div><div><=
br></div><div>I submit that these dividing lines are both unsustainable and=
 <i>have already been violated</i>.</div></div></blockquote><div><br></div>=
<div>I submit that the current situation is fine. We have guidelines, and w=
e have smart people in charge of making sure that reality follows those gui=
delines as closely as possible (but no closer).</div><div><br></div><div>Th=
e original source of the &quot;Attributes should not change semantics&quot;=
 guideline was N2761 &quot;Towards support for attributes in C++ (R6)&quot;=
, in 2008. Here is the complete text of the guidelines at the time, with hy=
perlinks to various original documents, which I collated the last time this=
 topic came up.</div><div><a onmousedown=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/m=
sg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ&#39;;return true;" href=3D"https://groups.=
google.com/a/isocpp.org/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ" target=3D"_bla=
nk" rel=3D"nofollow">https://groups.google.com/a/<wbr>isocpp.org/d/msg/sg14=
/IvKFg6-<wbr>9_Xo/PNj1kAntCQAJ</a><br></div><div>IMO, these guidelines have=
 held up very well. =C2=A0They are still quite sensible. =C2=A0I don&#39;t =
think N2761 has any embarrassing conflicts with the actual history of C++ s=
ince 2008.</div></div></blockquote><div><br></div><div>Are we reading the s=
ame N2761?</div><div><br></div><div>Under &quot;Good choices in attributes =
include:&quot;, they list &quot;final&quot;. Which was explicitly changed t=
o be a contextual keyword. The same goes with &quot;not_hiding&quot;, excep=
t that this was discarded entirely. And it says that `align` would be a goo=
d attribute, and it most assuredly is a keyword (though grammatically, it d=
oes go in the attribute section).</div><div><br></div><div>When you recomme=
nd that one thing would make a good attribute, and then everyone decides ex=
plicitly not to make it an attribute, I would call that an &quot;embarrassi=
ng conflict&quot;. When it happens<i> three times</i>, I&#39;d call it &quo=
t;nobody&#39;s listening to you&quot; ;)</div><div><i><br></i></div><div>Al=
so, let us consider the advice on when <i>not</i> to make something an attr=
ibute, and compare it to P0840:</div><div><u><br></u></div><div><u>* The fe=
ature is used in expressions as opposed to declarations.</u></div><div><u><=
br></u></div><div>Check: [[no_unique_address]] is used on declarations.</di=
v><div><u><br></u></div><div><u><span style=3D"text-align: left; color: rgb=
(34, 34, 34); text-transform: none; text-indent: 0px; letter-spacing: norma=
l; font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-si=
ze: 13px; font-style: normal; font-variant: normal; font-weight: 400; word-=
spacing: 0px; display: inline !important; white-space: normal; orphans: 2; =
float: none; -webkit-text-stroke-width: 0px; background-color: transparent;=
">* </span>The feature is of use to a broad audience.</u></div><div><u><br>=
</u></div><div>You can argue that [[no_unique_address]] is of limited use, =
but I very strongly disagree with this.<i> Every</i> C++ programmer should =
have this tool in their toolbox. It comes up very often as a basic point of=
 optimization.</div><div><u><br></u></div><div><u><span style=3D"text-align=
: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; let=
ter-spacing: normal; font-family: &quot;Arial&quot;,&quot;Helvetica&quot;,s=
ans-serif; font-size: 13px; font-style: normal; font-variant: normal; font-=
weight: 400; word-spacing: 0px; display: inline !important; white-space: no=
rmal; orphans: 2; float: none; -webkit-text-stroke-width: 0px; background-c=
olor: transparent;">* </span>The feature is a central part of the declarati=
on that significantly affects its requirements/semantics (e.g., constexpr).=
</u></div><div><u><br></u></div><div>Again, you can argue that [[no_unqiue_=
address]] doesn&#39;t &quot;significantly&quot; affect &quot;semantics&quot=
;, but I disagree. If it wasn&#39;t going to affect the behavior of the pro=
gram, you<i> wouldn&#39;t use it</i>.</div><div><i><u><br></u></i></div><di=
v><u><span style=3D"text-align: left; color: rgb(34, 34, 34); text-transfor=
m: none; text-indent: 0px; letter-spacing: normal; font-family: &quot;Arial=
&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style: norma=
l; font-variant: normal; font-weight: 400; word-spacing: 0px; display: inli=
ne !important; white-space: normal; orphans: 2; float: none; -webkit-text-s=
troke-width: 0px; background-color: transparent;">* </span>The feature modi=
fies the type system and/or overload resolution in a significant way (e.g.,=
 rvalue references).</u>=C2=A0 (However, something like near and far pointe=
rs should probably still be handled by attributes, although those do affect=
 the type system.)</div><div><br></div><div>Check; this doesn&#39;t modify =
the type system. Though I find the parenthetical to be essentially an admis=
sion that these guidelines are not really taken seriously.</div><div><u><br=
></u></div><div><u><span style=3D"text-align: left; color: rgb(34, 34, 34);=
 text-transform: none; text-indent: 0px; letter-spacing: normal; font-famil=
y: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fon=
t-style: normal; font-variant: normal; font-weight: 400; word-spacing: 0px;=
 display: inline !important; white-space: normal; orphans: 2; float: none; =
-webkit-text-stroke-width: 0px; background-color: transparent;">* </span>Th=
e feature is used everywhere on every instance of class, or statements</u><=
/div><div><u><br></u></div><div>It&#39;s not going to be <i>that</i> widely=
 used. But honestly, I think it&#39;ll be used more than people expect. Onc=
e people have a no-cost way of invoking this optimization, people will use =
it. I mean really, why<i> wouldn&#39;t</i> you use it whenever you&#39;re g=
iven a template argument type which you&#39;re going to make a member subob=
ject, but you only need one of them? It&#39;s not so much that you&#39;re e=
xpecting a gain, but... why throw away the possibility?</div><div><i><br></=
i></div><div>So by N2761&#39;s guidelines, [[no_unique_address]] should be =
a keyword, not an attribute. By Herb&#39;s general rule, it should be a key=
word. By P0840&#39;s own rules, it should be a keyword.</div><div><br></div=
><div>Yet it is an attribute.</div><div><br></div><div>How exactly is the c=
ommittee keeping to these guidelines?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div>What makes this unsustainable is this: what=
 we eventually want to do is make [[fallthrough]]<i> mandatory</i>. That is=
, to make it ill-formed to fall through without explicitly asking for it. T=
he problem is that we can&#39;t. So long as we stick to the above rules abo=
ut attributes, we cannot have the standard declare the lack of use of an at=
tribute to be ill-formed.<br></div></div></blockquote><div><br></div><div>I=
 think you&#39;re mixing senses of the word &quot;we&quot;.=C2=A0=C2=A0<b>I=
ndividual programmers</b> may want to make [[fallthrough]] mandatory or may=
 not, depending on their degree of paranoia and/or degree of spending time =
maintaining C code from the 1980s.=C2=A0=C2=A0<b>Individual vendors</b>=C2=
=A0are effectively free to make [[fallthrough]] mandatory today (and have g=
enerally already done so, in the recommended -W -Wall -Werror mode of invoc=
ation). =C2=A0<b>The ISO C++ Committee</b> indeed cannot declare the lack o=
f use of an attribute to be ill-formed, as long as the ISO C++ Committee st=
icks (strictly) to the above guidelines; but fortunately, I don&#39;t think=
 the ISO C++ Committee has much interest in sticking strictly to any guidel=
ine ever. =C2=A0Heck, they don&#39;t even stick to the <i>official ISO lang=
uage standard</i> for more than three years at a time anymore. ;)</div></di=
v></blockquote><div><br></div><div>If the committee doesn&#39;t follow its =
own guidelines, why have the guideline at all? Why not just openly declare,=
 &quot;hey, attributes really are just a way to get a low-cost keyword into=
 the language.&quot; I<span style=3D"display: inline !important; float: non=
e; background-color: transparent; color: rgb(34, 34, 34); font-family: &quo=
t;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; font-style=
: normal; font-variant: normal; font-weight: 400; letter-spacing: normal; o=
rphans: 2; text-align: left; text-decoration: none; text-indent: 0px; text-=
transform: none; -webkit-text-stroke-width: 0px; white-space: normal; word-=
spacing: 0px;">f you ignore a rule whenever it is convenient for you, then =
why have it?</span></div><div><b><br></b></div><div>Rules that aren&#39;t f=
ollowed are not rules.</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/094e32b8-2d97-43b0-a472-0e96752cd293%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/094e32b8-2d97-43b0-a472-0e96752cd293=
%40isocpp.org</a>.<br />

------=_Part_22803_1427533715.1514425690417--

------=_Part_22802_1952846971.1514425690416--

.

------=_Part_23540_707363598.1514448451411
Content-Type: multipart/alternative;
 boundary="----=_Part_23541_1709634818.1514448451411"

------=_Part_23541_1709634818.1514448451411
Content-Type: text/plain; charset="UTF-8"

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.

--
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/e360e4d8-b0cf-48b5-a4b0-320d1691f7de%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, December 27, 2017 at 10:44:13 PM UTC+3, miha=
iln...@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 di=
r=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 ag=
o.<br></div></div></blockquote><div>=C2=A0</div><div>inline can&#39;t be ig=
nored! It changes linkage of the  fuction.<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/e360e4d8-b0cf-48b5-a4b0-320d1691f7de%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e360e4d8-b0cf-48b5-a4b0-320d1691f7de=
%40isocpp.org</a>.<br />

------=_Part_23541_1709634818.1514448451411--

------=_Part_23540_707363598.1514448451411--

.

------=_Part_23415_628130781.1514450152423
Content-Type: multipart/alternative;
 boundary="----=_Part_23416_1212512664.1514450152423"

------=_Part_23416_1212512664.1514450152423
Content-Type: text/plain; charset="UTF-8"



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.

--
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/b3db6bb0-3dbf-4396-9415-5ce7f1f62076%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, December 28, 2017 at 10:07:31 AM UTC+=
2, Victor Dyachenko 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 Wednesday, December 27, 2017 at 10:44:13 PM UTC+3, <a>mihai=
ln...@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"><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=
..<br></div></div></blockquote><div>=C2=A0</div><div>inline can&#39;t be ign=
ored! It changes linkage of the  fuction.<br></div></div></blockquote><div>=
<br></div><div>It can not be ignored only in the context of multiple defini=
tions. In the context of the actual inlining it can be ignored. </div><div>=
Also, I don&#39;t think inline changes linkage - an inline function still h=
as external linkage.=C2=A0</div><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/b3db6bb0-3dbf-4396-9415-5ce7f1f62076%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b3db6bb0-3dbf-4396-9415-5ce7f1f62076=
%40isocpp.org</a>.<br />

------=_Part_23416_1212512664.1514450152423--

------=_Part_23415_628130781.1514450152423--

.

------=_Part_23423_1833744773.1514452199062
Content-Type: multipart/alternative;
 boundary="----=_Part_23424_1083439923.1514452199063"

------=_Part_23424_1083439923.1514452199063
Content-Type: text/plain; charset="UTF-8"

On Thursday, December 28, 2017 at 11:35:52 AM UTC+3, mihailn...@gmail.com
wrote:
>
> 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.
>

Try to define function in header without inline. You will see the difference

--
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/02ae4845-b468-4b6f-817b-1bb80412990a%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, December 28, 2017 at 11:35:52 AM UTC+3, mihai=
ln...@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">It can not be ignored only in the context of multiple definitions.=
 In the context of the actual inlining it can be ignored. <div>Also, I don&=
#39;t think inline changes linkage - an inline function still has external =
linkage. <br></div></div></blockquote><div><br></div><div>Try to define fun=
ction in header without inline. You will see the difference<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/02ae4845-b468-4b6f-817b-1bb80412990a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02ae4845-b468-4b6f-817b-1bb80412990a=
%40isocpp.org</a>.<br />

------=_Part_23424_1083439923.1514452199063--

------=_Part_23423_1833744773.1514452199062--

.

------=_Part_18978_2111587183.1514453304689
Content-Type: multipart/alternative;
 boundary="----=_Part_18979_73934764.1514453304689"

------=_Part_18979_73934764.1514453304689
Content-Type: text/plain; charset="UTF-8"



On Thursday, December 28, 2017 at 11:09:59 AM UTC+2, Victor Dyachenko wrote:
>
> On Thursday, December 28, 2017 at 11:35:52 AM UTC+3, mihailn...@gmail.com
> wrote:
>>
>> 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.
>>
>
> Try to define function in header without inline. You will see the
> difference
>

This has nothing to do with linkage, only with ODR.

--
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/4fd75d64-6d07-464c-9385-f7a09f7adbd0%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, December 28, 2017 at 11:09:59 AM UTC+=
2, Victor Dyachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr">On Thursday, December 28, 2017 at 11:35:52 AM UTC+3, <a>mihail=
n...@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">It can not be ignored only in the context of multiple definitions.=
 In the context of the actual inlining it can be ignored. <div>Also, I don&=
#39;t think inline changes linkage - an inline function still has external =
linkage. <br></div></div></blockquote><div><br></div><div>Try to define fun=
ction in header without inline. You will see the difference<br></div></div>=
</blockquote><div><br></div><div>This has nothing to do with linkage, only =
with ODR. =C2=A0</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/4fd75d64-6d07-464c-9385-f7a09f7adbd0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4fd75d64-6d07-464c-9385-f7a09f7adbd0=
%40isocpp.org</a>.<br />

------=_Part_18979_73934764.1514453304689--

------=_Part_18978_2111587183.1514453304689--

.

------=_Part_23010_223573489.1514453604397
Content-Type: multipart/alternative;
 boundary="----=_Part_23011_2051101038.1514453604397"

------=_Part_23011_2051101038.1514453604397
Content-Type: text/plain; charset="UTF-8"

On Thursday, December 28, 2017 at 12:28:24 PM UTC+3, mihailn...@gmail.com
wrote:
>
>
> This has nothing to do with linkage, only with ODR.
>

inline is a part of function declaration. It affects the semantics. It
isn't just an "optimization hint"

--
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/c13a1ef4-e729-4d79-9393-995f6d745799%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, December 28, 2017 at 12:28:24 PM UTC+3, mihai=
ln...@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><div>This has nothing to do with linkage, only with ODR. =C2=
=A0</div></div></blockquote><div><br></div><div>inline is a part of functio=
n declaration. It affects the semantics. It isn&#39;t just an &quot;optimiz=
ation hint&quot;<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/c13a1ef4-e729-4d79-9393-995f6d745799%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c13a1ef4-e729-4d79-9393-995f6d745799=
%40isocpp.org</a>.<br />

------=_Part_23011_2051101038.1514453604397--

------=_Part_23010_223573489.1514453604397--

.

------=_Part_23489_76181458.1514454818839
Content-Type: multipart/alternative;
 boundary="----=_Part_23490_666559859.1514454818839"

------=_Part_23490_666559859.1514454818839
Content-Type: text/plain; charset="UTF-8"



On Thursday, December 28, 2017 at 11:33:24 AM UTC+2, Victor Dyachenko wrote:
>
> On Thursday, December 28, 2017 at 12:28:24 PM UTC+3, mihailn...@gmail.com
> wrote:
>>
>>
>> This has nothing to do with linkage, only with ODR.
>>
>
> inline is a part of function declaration. It affects the semantics. It
> isn't just an "optimization hint"
>

It has two meanings - one is optimization hint, one is "let me get around
ODR (I promise I will behave)".
The first can be ignored and has no semantic value, the second can not be
ignored and does have semantic value, *especially* regarding inline
variables.

So, in a way, I was only half-right in my original comment. However, you
could use inline only for its first use case and ignore the second,
suffering the limitations.

--
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/defb94be-0f48-41cf-9272-d5816ac14b07%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, December 28, 2017 at 11:33:24 AM UTC+=
2, Victor Dyachenko wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr">On Thursday, December 28, 2017 at 12:28:24 PM UTC+3, <a>mihail=
n...@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"><br><div>This has nothing to do with linkage, only with ODR. =C2=
=A0</div></div></blockquote><div><br></div><div>inline is a part of functio=
n declaration. It affects the semantics. It isn&#39;t just an &quot;optimiz=
ation hint&quot;<br></div></div></blockquote><div><br></div><div>It has two=
 meanings - one is optimization hint, one is &quot;let me get around ODR (I=
 promise I will behave)&quot;.</div><div>The first can be ignored and has n=
o semantic value, the second can not be ignored and does have semantic valu=
e, <i>especially</i> regarding inline variables.</div><div><br></div><div>S=
o, in a way, I was only half-right in my original comment. However, you cou=
ld use inline only for its first use case and ignore the second, suffering =
the limitations.=C2=A0</div><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/defb94be-0f48-41cf-9272-d5816ac14b07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/defb94be-0f48-41cf-9272-d5816ac14b07=
%40isocpp.org</a>.<br />

------=_Part_23490_666559859.1514454818839--

------=_Part_23489_76181458.1514454818839--

.

------=_Part_25282_1419975105.1514510981372
Content-Type: multipart/alternative;
 boundary="----=_Part_25283_658755980.1514510981372"

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



On Thursday, December 28, 2017 at 2:48:10 AM UTC+1, Nicol Bolas wrote:
>
> On Wednesday, December 27, 2017 at 5:37:32 PM UTC-5, Arthur O'Dwyer wrote=
:
>>
>> On Wednesday, December 27, 2017 at 10:15:35 AM UTC-8, Nicol Bolas wrote:
>>>
>>> There is clearly intended to be a dividing line between C++ attributes=
=20
>>> and C++ keywords.
>>>
>>> Herb Sutter outlined one version of this division=20
>>> <https://herbsutter.com/2012/04/02/reader-qa-keywords-and-attributes/>.=
=20
>>> As he states:
>>>
>>> > [[attributes]] are specifically designed to be ignorable and shouldn=
=E2=80=99t=20
>>> be used for things having language semantic meaning.
>>>
>>> P0840=20
>>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0840r0.html>=
=20
>>> offers a different but similar division:
>>>
>>> > compiling a valid program with all instances of a particular attribut=
e=20
>>> ignored must result in a correct interpretation of the original program
>>>
>>> I submit that these dividing lines are both unsustainable and *have=20
>>> already been violated*.
>>>
>>
>> I submit that the current situation is fine. We have guidelines, and we=
=20
>> have smart people in charge of making sure that reality follows those=20
>> guidelines as closely as possible (but no closer).
>>
>> The original source of the "Attributes should not change semantics"=20
>> guideline was N2761 "Towards support for attributes in C++ (R6)", in 200=
8.=20
>> Here is the complete text of the guidelines at the time, with hyperlinks=
 to=20
>> various original documents, which I collated the last time this topic ca=
me=20
>> up.
>> https://groups.google.com/a/isocpp.org/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQ=
AJ
>> IMO, these guidelines have held up very well.  They are still quite=20
>> sensible.  I don't think N2761 has any embarrassing conflicts with the=
=20
>> actual history of C++ since 2008.
>>
>
> Are we reading the same N2761?
>
> Under "Good choices in attributes include:", they list "final". Which was=
=20
> explicitly changed to be a contextual keyword. The same goes with=20
> "not_hiding", except that this was discarded entirely. And it says that=
=20
> `align` would be a good attribute, and it most assuredly is a keyword=20
> (though grammatically, it does go in the attribute section).
>
> When you recommend that one thing would make a good attribute, and then=
=20
> everyone decides explicitly not to make it an attribute, I would call tha=
t=20
> an "embarrassing conflict". When it happens* three times*, I'd call it=20
> "nobody's listening to you" ;)
>
> Also, let us consider the advice on when *not* to make something an=20
> attribute, and compare it to P0840:
>
> ** The feature is used in expressions as opposed to declarations.*
>
> Check: [[no_unique_address]] is used on declarations.
>
> ** The feature is of use to a broad audience.*
>
> You can argue that [[no_unique_address]] is of limited use, but I very=20
> strongly disagree with this.* Every* C++ programmer should have this tool=
=20
> in their toolbox. It comes up very often as a basic point of optimization=
..
>
> ** The feature is a central part of the declaration that significantly=20
> affects its requirements/semantics (e.g., constexpr).*
>
> Again, you can argue that [[no_unqiue_address]] doesn't "significantly"=
=20
> affect "semantics", but I disagree. If it wasn't going to affect the=20
> behavior of the program, you* wouldn't use it*.
>
> ** The feature modifies the type system and/or overload resolution in a=
=20
> significant way (e.g., rvalue references).*  (However, something like=20
> near and far pointers should probably still be handled by attributes,=20
> although those do affect the type system.)
>
> Check; this doesn't modify the type system. Though I find the=20
> parenthetical to be essentially an admission that these guidelines are no=
t=20
> really taken seriously.
>
> ** The feature is used everywhere on every instance of class, or=20
> statements*
>
> It's not going to be *that* widely used. But honestly, I think it'll be=
=20
> used more than people expect. Once people have a no-cost way of invoking=
=20
> this optimization, people will use it. I mean really, why* wouldn't* you=
=20
> use it whenever you're given a template argument type which you're going =
to=20
> make a member subobject, but you only need one of them? It's not so much=
=20
> that you're expecting a gain, but... why throw away the possibility?
>
> So by N2761's guidelines, [[no_unique_address]] should be a keyword, not=
=20
> an attribute. By Herb's general rule, it should be a keyword. By P0840's=
=20
> own rules, it should be a keyword.
>
> Yet it is an attribute.
>
> How exactly is the committee keeping to these guidelines?
>
> What makes this unsustainable is this: what we eventually want to do is=
=20
>>> make [[fallthrough]]* mandatory*. That is, to make it ill-formed to=20
>>> fall through without explicitly asking for it. The problem is that we=
=20
>>> can't. So long as we stick to the above rules about attributes, we cann=
ot=20
>>> have the standard declare the lack of use of an attribute to be ill-for=
med.
>>>
>>
>> I think you're mixing senses of the word "we".  *Individual programmers*=
=20
>> may want to make [[fallthrough]] mandatory or may not, depending on thei=
r=20
>> degree of paranoia and/or degree of spending time maintaining C code fro=
m=20
>> the 1980s.  *Individual vendors* are effectively free to make=20
>> [[fallthrough]] mandatory today (and have generally already done so, in =
the=20
>> recommended -W -Wall -Werror mode of invocation).  *The ISO C++=20
>> Committee* indeed cannot declare the lack of use of an attribute to be=
=20
>> ill-formed, as long as the ISO C++ Committee sticks (strictly) to the ab=
ove=20
>> guidelines; but fortunately, I don't think the ISO C++ Committee has muc=
h=20
>> interest in sticking strictly to any guideline ever.  Heck, they don't e=
ven=20
>> stick to the *official ISO language standard* for more than three years=
=20
>> at a time anymore. ;)
>>
>
> If the committee doesn't follow its own guidelines, why have the guidelin=
e=20
> at all? Why not just openly declare, "hey, attributes really are just a w=
ay=20
> to get a low-cost keyword into the language." If you ignore a rule=20
> whenever it is convenient for you, then why have it?
>
> Rules that aren't followed are not rules.
>
=20
For me `[[no_unique_address]]` should only affect size and address of=20
member, nothing more. If this things could change between implementations=
=20
and ABI then this attribute could affect this.
But this will need that object do not have standard layout, that from=20
previous thread conclusion is this will remove lot of types that happened=
=20
to not have this property.

Probably to maintain current behavior this should be a keyword.

For overall attribute guidelines it could be things that can be check=20
outside of compiler, compiler can use but is not required do do this.
We can see if we define attribute `[[user_from_provided]]` and=20
`[[escaped_value]]` used in web app. With them you can't mix them without=
=20
static cast:
[[user_from_provided]] string user_name =3D "' drop table users; --";
[[escaped_value]] string sql;
sql =3D user_name; //error!
sql =3D static_cast<string>(user_name); //ok
If you write correct code that obey this attributes compiler will work fine=
=20
even if it do not understand what they mean, only if you write it wrong=20
compiler will ignore error, but this could be check at some time later by=
=20
some tool or other person with correct compiler. In case of=20
`[[no_unique_address]]` we could forbid taking address or offset of member,=
=20
then you could not detect if some object have same address. Only problem=20
would be it will be hard to enforce and check in compile time (some member=
=20
function of this member could take address).


--=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/fbc43dd0-ab76-4ebb-9059-c104f7eba61e%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>On Thursday, December 28, 2017 at 2:48:10 AM 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:37:32 PM UTC-5, 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 Wed=
nesday, December 27, 2017 at 10:15:35 AM UTC-8, Nicol Bolas wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There is clearly inten=
ded to be a dividing line between C++ attributes and C++ keywords.</div><di=
v><br></div><div>Herb Sutter <a href=3D"https://herbsutter.com/2012/04/02/r=
eader-qa-keywords-and-attributes/" rel=3D"nofollow" target=3D"_blank" onmou=
sedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fhe=
rbsutter.com%2F2012%2F04%2F02%2Freader-qa-keywords-and-attributes%2F\x26sa\=
x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbFG4_kMN2lB4sho01UUyGR606Yg&#39;;return =
true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A=
%2F%2Fherbsutter.com%2F2012%2F04%2F02%2Freader-qa-keywords-and-attributes%2=
F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGbFG4_kMN2lB4sho01UUyGR606Yg&#39;=
;return true;">outlined one version of this division</a>. As he states:</di=
v><div><br></div><div>&gt;=C2=A0[[attributes]] are specifically designed to=
 be ignorable and shouldn=E2=80=99t be used for things having language sema=
ntic meaning.</div><div><br></div><div><a href=3D"http://www.open-std.org/J=
TC1/SC22/WG21/docs/papers/2017/p0840r0.html" rel=3D"nofollow" target=3D"_bl=
ank" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A=
%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0840r=
0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErg6DrPIy-NrUzpoBnQvvMw_DJfg=
&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q=
\x3dhttp%3A%2F%2Fwww.open-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F20=
17%2Fp0840r0.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErg6DrPIy-NrUzpoB=
nQvvMw_DJfg&#39;;return true;">P0840</a> offers a different but similar div=
ision:</div><div><br></div><div>&gt;=C2=A0compiling a valid program with al=
l instances of a particular attribute ignored
must result in a correct interpretation of the original program</div><div><=
br></div><div>I submit that these dividing lines are both unsustainable and=
 <i>have already been violated</i>.</div></div></blockquote><div><br></div>=
<div>I submit that the current situation is fine. We have guidelines, and w=
e have smart people in charge of making sure that reality follows those gui=
delines as closely as possible (but no closer).</div><div><br></div><div>Th=
e original source of the &quot;Attributes should not change semantics&quot;=
 guideline was N2761 &quot;Towards support for attributes in C++ (R6)&quot;=
, in 2008. Here is the complete text of the guidelines at the time, with hy=
perlinks to various original documents, which I collated the last time this=
 topic came up.</div><div><a href=3D"https://groups.google.com/a/isocpp.org=
/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQAJ" rel=3D"nofollow" target=3D"_blank" on=
mousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msg/=
sg14/IvKFg6-9_Xo/PNj1kAntCQAJ&#39;;return true;" onclick=3D"this.href=3D&#3=
9;https://groups.google.com/a/isocpp.org/d/msg/sg14/IvKFg6-9_Xo/PNj1kAntCQA=
J&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.org/d/msg/sg14=
/IvKFg6-<wbr>9_Xo/PNj1kAntCQAJ</a><br></div><div>IMO, these guidelines have=
 held up very well. =C2=A0They are still quite sensible. =C2=A0I don&#39;t =
think N2761 has any embarrassing conflicts with the actual history of C++ s=
ince 2008.</div></div></blockquote><div><br></div><div>Are we reading the s=
ame N2761?</div><div><br></div><div>Under &quot;Good choices in attributes =
include:&quot;, they list &quot;final&quot;. Which was explicitly changed t=
o be a contextual keyword. The same goes with &quot;not_hiding&quot;, excep=
t that this was discarded entirely. And it says that `align` would be a goo=
d attribute, and it most assuredly is a keyword (though grammatically, it d=
oes go in the attribute section).</div><div><br></div><div>When you recomme=
nd that one thing would make a good attribute, and then everyone decides ex=
plicitly not to make it an attribute, I would call that an &quot;embarrassi=
ng conflict&quot;. When it happens<i> three times</i>, I&#39;d call it &quo=
t;nobody&#39;s listening to you&quot; ;)</div><div><i><br></i></div><div>Al=
so, let us consider the advice on when <i>not</i> to make something an attr=
ibute, and compare it to P0840:</div><div><u><br></u></div><div><u>* The fe=
ature is used in expressions as opposed to declarations.</u></div><div><u><=
br></u></div><div>Check: [[no_unique_address]] is used on declarations.</di=
v><div><u><br></u></div><div><u><span style=3D"text-align:left;color:rgb(34=
,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;font-fami=
ly:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-s=
tyle:normal;font-variant:normal;font-weight:400;word-spacing:0px;display:in=
line!important;white-space:normal;float:none;background-color:transparent">=
* </span>The feature is of use to a broad audience.</u></div><div><u><br></=
u></div><div>You can argue that [[no_unique_address]] is of limited use, bu=
t I very strongly disagree with this.<i> Every</i> C++ programmer should ha=
ve this tool in their toolbox. It comes up very often as a basic point of o=
ptimization.</div><div><u><br></u></div><div><u><span style=3D"text-align:l=
eft;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:=
normal;font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;font-=
size:13px;font-style:normal;font-variant:normal;font-weight:400;word-spacin=
g:0px;display:inline!important;white-space:normal;float:none;background-col=
or:transparent">* </span>The feature is a central part of the declaration t=
hat significantly affects its requirements/semantics (e.g., constexpr).</u>=
</div><div><u><br></u></div><div>Again, you can argue that [[no_unqiue_addr=
ess]] doesn&#39;t &quot;significantly&quot; affect &quot;semantics&quot;, b=
ut I disagree. If it wasn&#39;t going to affect the behavior of the program=
, you<i> wouldn&#39;t use it</i>.</div><div><i><u><br></u></i></div><div><u=
><span style=3D"text-align:left;color:rgb(34,34,34);text-transform:none;tex=
t-indent:0px;letter-spacing:normal;font-family:&quot;Arial&quot;,&quot;Helv=
etica&quot;,sans-serif;font-size:13px;font-style:normal;font-variant:normal=
;font-weight:400;word-spacing:0px;display:inline!important;white-space:norm=
al;float:none;background-color:transparent">* </span>The feature modifies t=
he type system and/or overload resolution in a significant way (e.g., rvalu=
e references).</u>=C2=A0 (However, something like near and far pointers sho=
uld probably still be handled by attributes, although those do affect the t=
ype system.)</div><div><br></div><div>Check; this doesn&#39;t modify the ty=
pe system. Though I find the parenthetical to be essentially an admission t=
hat these guidelines are not really taken seriously.</div><div><u><br></u><=
/div><div><u><span style=3D"text-align:left;color:rgb(34,34,34);text-transf=
orm:none;text-indent:0px;letter-spacing:normal;font-family:&quot;Arial&quot=
;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-va=
riant:normal;font-weight:400;word-spacing:0px;display:inline!important;whit=
e-space:normal;float:none;background-color:transparent">* </span>The featur=
e is used everywhere on every instance of class, or statements</u></div><di=
v><u><br></u></div><div>It&#39;s not going to be <i>that</i> widely used. B=
ut honestly, I think it&#39;ll be used more than people expect. Once people=
 have a no-cost way of invoking this optimization, people will use it. I me=
an really, why<i> wouldn&#39;t</i> you use it whenever you&#39;re given a t=
emplate argument type which you&#39;re going to make a member subobject, bu=
t you only need one of them? It&#39;s not so much that you&#39;re expecting=
 a gain, but... why throw away the possibility?</div><div><i><br></i></div>=
<div>So by N2761&#39;s guidelines, [[no_unique_address]] should be a keywor=
d, not an attribute. By Herb&#39;s general rule, it should be a keyword. By=
 P0840&#39;s own rules, it should be a keyword.</div><div><br></div><div>Ye=
t it is an attribute.</div><div><br></div><div>How exactly is the committee=
 keeping to these guidelines?</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><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>What makes this unsustainable is this: what we eventuall=
y want to do is make [[fallthrough]]<i> mandatory</i>. That is, to make it =
ill-formed to fall through without explicitly asking for it. The problem is=
 that we can&#39;t. So long as we stick to the above rules about attributes=
, we cannot have the standard declare the lack of use of an attribute to be=
 ill-formed.<br></div></div></blockquote><div><br></div><div>I think you&#3=
9;re mixing senses of the word &quot;we&quot;.=C2=A0=C2=A0<b>Individual pro=
grammers</b> may want to make [[fallthrough]] mandatory or may not, dependi=
ng on their degree of paranoia and/or degree of spending time maintaining C=
 code from the 1980s.=C2=A0=C2=A0<b>Individual vendors</b>=C2=A0are effecti=
vely free to make [[fallthrough]] mandatory today (and have generally alrea=
dy done so, in the recommended -W -Wall -Werror mode of invocation). =C2=A0=
<b>The ISO C++ Committee</b> indeed cannot declare the lack of use of an at=
tribute to be ill-formed, as long as the ISO C++ Committee sticks (strictly=
) to the above guidelines; but fortunately, I don&#39;t think the ISO C++ C=
ommittee has much interest in sticking strictly to any guideline ever. =C2=
=A0Heck, they don&#39;t even stick to the <i>official ISO language standard=
</i> for more than three years at a time anymore. ;)</div></div></blockquot=
e><div><br></div><div>If the committee doesn&#39;t follow its own guideline=
s, why have the guideline at all? Why not just openly declare, &quot;hey, a=
ttributes really are just a way to get a low-cost keyword into the language=
..&quot; I<span style=3D"display:inline!important;float:none;background-colo=
r:transparent;color:rgb(34,34,34);font-family:&quot;Arial&quot;,&quot;Helve=
tica&quot;,sans-serif;font-size: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">f =
you ignore a rule whenever it is convenient for you, then why have it?</spa=
n></div><div><b><br></b></div><div>Rules that aren&#39;t followed are not r=
ules.</div></div></blockquote><div>=C2=A0</div><div>For me `[[no_unique_add=
ress]]` should only affect size and address of member, nothing more. If thi=
s things could change between implementations and ABI then this attribute c=
ould affect this.</div><div>But this will need that object do not have stan=
dard layout, that from previous thread conclusion is this will remove lot o=
f types that happened to not have this property.</div><div><br></div><div>P=
robably to maintain current behavior this should be a keyword.</div><div><b=
r></div><div>For overall attribute guidelines it could be things that can b=
e check outside of compiler, compiler can use but is not required do do thi=
s.</div><div>We can see if we define attribute `[[user_from_provided]]` and=
 `[[escaped_value]]` used in web app. With them you can&#39;t mix them with=
out static cast:</div><div><div style=3D"background-color: rgb(250, 250, 25=
0); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1p=
x; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">[[</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">user_from_provided</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">]]</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">string</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> u=
ser_name </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #080;" class=3D"styled-by-prettify">&quot;&#39; drop=
 table users; --&quot;</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">escaped_val=
ue</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]]</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> sql</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>sql </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> user_name</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pret=
tify">//error!</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>sql </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">static_cast</s=
pan><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;string&gt=
;</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">user_name</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">//ok</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div>If you write=
 correct code that obey this attributes compiler will work fine even if it =
do not understand what they mean, only if you write it wrong compiler will =
ignore error, but this could be check at some time later by some tool or ot=
her person with correct compiler. In case of  `[[no_unique_address]]` we co=
uld forbid taking address or offset of member, then you could not detect if=
 some object have same address. Only problem would be it will be hard to en=
force and check in compile time (some member function of this member could =
take address).<br><br></div><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/fbc43dd0-ab76-4ebb-9059-c104f7eba61e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fbc43dd0-ab76-4ebb-9059-c104f7eba61e=
%40isocpp.org</a>.<br />

------=_Part_25283_658755980.1514510981372--

------=_Part_25282_1419975105.1514510981372--

.

------=_Part_26763_859133996.1514535999049
Content-Type: multipart/alternative;
 boundary="----=_Part_26764_142514518.1514535999049"

------=_Part_26764_142514518.1514535999049
Content-Type: text/plain; charset="UTF-8"

....

> In case of `[[no_unique_address]]` we could forbid taking address or
> offset of member, then you could not detect if some object have same
> address. Only problem would be it will be hard to enforce and check in
> compile time (some member function of this member could take address).
>
>
>
The problem with  [[no_unique_address]] has nothing to do with addresses,
but the fact, given this code:

struct Alloc {};

template<typename Allocator=Alloc>
struct cool_boy
{
  [[no_unique_address]] Allocator alloc;
};

This user code will fail to compile if the attr is ignored.

struct innocent_use
{
  template<class Cool, template = std::enable_if_t<std::is_empty_v<Cool>>>
  innocent_use(Cool&&) { }
};

innocent_use use{cool_boy{}};

"Or worse" if another overload is present.


--
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/7141e0f8-e0d5-497e-b13b-77669e0520c5%40isocpp.org.

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

<div dir=3D"ltr"><div>...=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div>In case of  `[[no_unique_address]]` we could f=
orbid taking address or offset of member, then you could not detect if some=
 object have same address. Only problem would be it will be hard to enforce=
 and check in compile time (some member function of this member could take =
address).<br><br></div><div><br></div></div></blockquote><div><br></div><di=
v>The problem with=C2=A0=C2=A0<span style=3D"display: inline !important; fl=
oat: none; background-color: transparent; color: rgb(34, 34, 34); font-fami=
ly: &quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif; font-size: 13px; fo=
nt-style: normal; font-variant: normal; font-weight: 400; letter-spacing: n=
ormal; orphans: 2; text-align: left; text-decoration: none; text-indent: 0p=
x; text-transform: none; -webkit-text-stroke-width: 0px; white-space: norma=
l; word-spacing: 0px;">[[no_unique_address]] has nothing to do with address=
es, but the fact, given this code:</span></div><div><br></div><div><font fa=
ce=3D"courier new,monospace">struct Alloc {};</font><span style=3D"text-ali=
gn: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; l=
etter-spacing: normal; font-size: 13px; font-style: normal; font-variant: n=
ormal; font-weight: 400; text-decoration: none; word-spacing: 0px; display:=
 inline !important; white-space: normal; orphans: 2; float: none; -webkit-t=
ext-stroke-width: 0px; background-color: transparent;"><br></span></div><sp=
an style=3D"display: inline !important; float: none; background-color: tran=
sparent; color: rgb(34, 34, 34); font-family: &quot;Arial&quot;,&quot;Helve=
tica&quot;,sans-serif; font-size: 13px; font-style: normal; font-variant: n=
ormal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: le=
ft; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-=
text-stroke-width: 0px; white-space: normal; word-spacing: 0px;"><div><font=
 face=3D"courier new,monospace"></font><br></div></span><div><span style=3D=
"text-align: left; color: rgb(34, 34, 34); text-transform: none; text-inden=
t: 0px; letter-spacing: normal; font-size: 13px; font-variant: normal; word=
-spacing: 0px; display: inline !important; white-space: normal; orphans: 2;=
 float: none; -webkit-text-stroke-width: 0px; background-color: transparent=
;"><span style=3D"text-align: left; color: rgb(0, 0, 0); text-transform: no=
ne; text-indent: 0px; letter-spacing: normal; font-size: 13.33px; font-styl=
e: normal; font-variant: normal; font-weight: 400; text-decoration: none; w=
ord-spacing: 0px; display: inline !important; white-space: pre; orphans: 2;=
 float: none; -webkit-text-stroke-width: 0px; background-color: transparent=
;"><font face=3D"courier new,monospace">template&lt;typename Allocator=3DAl=
loc&gt;<br>struct cool_boy </font></span></span></div><div><span style=3D"t=
ext-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent:=
 0px; letter-spacing: normal; font-size: 13px; font-variant: normal; word-s=
pacing: 0px; display: inline !important; white-space: normal; orphans: 2; f=
loat: none; -webkit-text-stroke-width: 0px; background-color: transparent;"=
><span style=3D"text-align: left; color: rgb(0, 0, 0); text-transform: none=
; text-indent: 0px; letter-spacing: normal; font-size: 13.33px; font-style:=
 normal; font-variant: normal; font-weight: 400; text-decoration: none; wor=
d-spacing: 0px; display: inline !important; white-space: pre; orphans: 2; f=
loat: none; -webkit-text-stroke-width: 0px; background-color: transparent;"=
><font face=3D"courier new,monospace">{<br>=C2=A0 [[no_unique_address]] All=
ocator alloc;<br>};</font></span></span></div><div><span style=3D"text-alig=
n: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; le=
tter-spacing: normal; font-size: 13px; font-variant: normal; word-spacing: =
0px; display: inline !important; white-space: normal; orphans: 2; float: no=
ne; -webkit-text-stroke-width: 0px; background-color: transparent;"><span s=
tyle=3D"text-align: left; color: rgb(0, 0, 0); text-transform: none; text-i=
ndent: 0px; letter-spacing: normal; font-size: 13.33px; font-style: normal;=
 font-variant: normal; font-weight: 400; text-decoration: none; word-spacin=
g: 0px; display: inline !important; white-space: pre; orphans: 2; float: no=
ne; -webkit-text-stroke-width: 0px; background-color: transparent;"><font f=
ace=3D"courier new"><br></font></span></span></div><div><span style=3D"text=
-align: left; color: rgb(34, 34, 34); text-transform: none; text-indent: 0p=
x; letter-spacing: normal; font-size: 13px; font-variant: normal; word-spac=
ing: 0px; display: inline !important; white-space: normal; orphans: 2; floa=
t: none; -webkit-text-stroke-width: 0px; background-color: transparent;"><s=
pan style=3D"text-align: left; color: rgb(0, 0, 0); text-transform: none; t=
ext-indent: 0px; letter-spacing: normal; font-size: 13.33px; font-style: no=
rmal; font-variant: normal; font-weight: 400; text-decoration: none; word-s=
pacing: 0px; display: inline !important; white-space: pre; orphans: 2; floa=
t: none; -webkit-text-stroke-width: 0px; background-color: transparent;"><f=
ont face=3D"arial,sans-serif">This user code will fail to compile if the at=
tr is ignored.</font></span></span></div><div><span style=3D"text-align: le=
ft; color: rgb(34, 34, 34); text-transform: none; text-indent: 0px; letter-=
spacing: normal; font-size: 13px; font-variant: normal; word-spacing: 0px; =
display: inline !important; white-space: normal; orphans: 2; float: none; -=
webkit-text-stroke-width: 0px; background-color: transparent;"><span style=
=3D"text-align: left; color: rgb(0, 0, 0); text-transform: none; text-inden=
t: 0px; letter-spacing: normal; font-size: 13.33px; font-style: normal; fon=
t-variant: normal; font-weight: 400; text-decoration: none; word-spacing: 0=
px; display: inline !important; white-space: pre; orphans: 2; float: none; =
-webkit-text-stroke-width: 0px; background-color: transparent;"><br></span>=
</span></div><div><font face=3D"courier new,monospace">struct innocent_use<=
br>{<br>=C2=A0 template&lt;class Cool, template =3D std::enable_if_t&lt;std=
::is_empty_v&lt;Cool&gt;&gt;&gt;<br>=C2=A0 innocent_use(Cool&amp;&amp;) { }=
<br>};</font></div><div><font face=3D"courier new"><br></font></div><div><f=
ont face=3D"courier new"><span style=3D"display: inline !important; float: =
none; background-color: transparent; color: rgb(34, 34, 34); font-family: c=
ourier new,monospace; font-size: 13px; font-style: normal; font-variant: no=
rmal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: lef=
t; text-decoration: none; text-indent: 0px; text-transform: none; -webkit-t=
ext-stroke-width: 0px; white-space: normal; word-spacing: 0px;">innocent_us=
e use{<span style=3D"background-color: transparent; border-bottom-color: rg=
b(0, 0, 0); border-bottom-style: none; border-bottom-width: 0px; border-ima=
ge-outset: 0; border-image-repeat: stretch; border-image-slice: 100%; borde=
r-image-source: none; border-image-width: 1; border-left-color: rgb(0, 0, 0=
); border-left-style: none; border-left-width: 0px; border-right-color: rgb=
(0, 0, 0); border-right-style: none; border-right-width: 0px; border-top-co=
lor: rgb(0, 0, 0); border-top-style: none; border-top-width: 0px; color: rg=
b(0, 0, 0); display: inline; float: none; font-family: courier new,monospac=
e; font-size: 13.33px; font-style: normal; font-variant: normal; font-weigh=
t: 400; letter-spacing: normal; margin-bottom: 0px; margin-left: 0px; margi=
n-right: 0px; margin-top: 0px; orphans: 2; padding-bottom: 0px; padding-lef=
t: 0px; padding-right: 0px; padding-top: 0px; text-align: left; text-decora=
tion: none; text-indent: 0px; text-transform: none; -webkit-text-stroke-wid=
th: 0px; white-space: pre; word-spacing: 0px;">cool_boy{}</span>};</span></=
font></div><div></div><div><br></div><div>&quot;Or worse&quot; if another o=
verload is present.=C2=A0</div><div><font color=3D"#007670" face=3D"courier=
 new" size=3D"2"><br></font></div><div><font color=3D"#000111" face=3D"cour=
ier new" size=3D"2"><br></font></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/7141e0f8-e0d5-497e-b13b-77669e0520c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7141e0f8-e0d5-497e-b13b-77669e0520c5=
%40isocpp.org</a>.<br />

------=_Part_26764_142514518.1514535999049--

------=_Part_26763_859133996.1514535999049--

.

------=_Part_27823_679545475.1514570459183
Content-Type: multipart/alternative;
 boundary="----=_Part_27824_1411240351.1514570459183"

------=_Part_27824_1411240351.1514570459183
Content-Type: text/plain; charset="UTF-8"



On Friday, December 29, 2017 at 9:26:39 AM UTC+1, mihailn...@gmail.com
wrote:
>
> ...
>
>> In case of `[[no_unique_address]]` we could forbid taking address or
>> offset of member, then you could not detect if some object have same
>> address. Only problem would be it will be hard to enforce and check in
>> compile time (some member function of this member could take address).
>>
>>
>>
> The problem with  [[no_unique_address]] has nothing to do with addresses,
> but the fact, given this code:
>
> struct Alloc {};
>
> template<typename Allocator=Alloc>
> struct cool_boy
> {
>   [[no_unique_address]] Allocator alloc;
> };
>
> This user code will fail to compile if the attr is ignored.
>
> struct innocent_use
> {
>   template<class Cool, template = std::enable_if_t<std::is_empty_v<Cool>>>
>   innocent_use(Cool&&) { }
> };
>
> innocent_use use{cool_boy{}};
>
> "Or worse" if another overload is present.
>
>
>
Of corse, this why I said couple lines before "should only affect size and
address of member, nothing more".

--
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/91e1487d-aff5-4b35-835c-58d71546572b%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, December 29, 2017 at 9:26:39 AM UTC+1, =
mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>...=C2=A0</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>In case of  `[[no_unique_address]]` we could forbid =
taking address or offset of member, then you could not detect if some objec=
t have same address. Only problem would be it will be hard to enforce and c=
heck in compile time (some member function of this member could take addres=
s).<br><br></div><div><br></div></div></blockquote><div><br></div><div>The =
problem with=C2=A0=C2=A0<span style=3D"display:inline!important;float:none;=
background-color:transparent;color:rgb(34,34,34);font-family:&quot;Arial&qu=
ot;,&quot;Helvetica&quot;,sans-serif;font-size:13px;font-style:normal;font-=
variant:normal;font-weight:400;letter-spacing:normal;text-align:left;text-d=
ecoration:none;text-indent:0px;text-transform:none;white-space:normal;word-=
spacing:0px">[[no_unique_address]] has nothing to do with addresses, but th=
e fact, given this code:</span></div><div><br></div><div><font face=3D"cour=
ier new,monospace">struct Alloc {};</font><span style=3D"text-align:left;co=
lor:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal=
;font-size:13px;font-style:normal;font-variant:normal;font-weight:400;text-=
decoration:none;word-spacing:0px;display:inline!important;white-space:norma=
l;float:none;background-color:transparent"><br></span></div><span style=3D"=
display:inline!important;float:none;background-color:transparent;color:rgb(=
34,34,34);font-family:&quot;Arial&quot;,&quot;Helvetica&quot;,sans-serif;fo=
nt-size:13px;font-style:normal;font-variant:normal;font-weight:400;letter-s=
pacing:normal;text-align:left;text-decoration:none;text-indent:0px;text-tra=
nsform:none;white-space:normal;word-spacing:0px"><div><font face=3D"courier=
 new,monospace"></font><br></div></span><div><span style=3D"text-align:left=
;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:nor=
mal;font-size:13px;font-variant:normal;word-spacing:0px;display:inline!impo=
rtant;white-space:normal;float:none;background-color:transparent"><span sty=
le=3D"text-align:left;color:rgb(0,0,0);text-transform:none;text-indent:0px;=
letter-spacing:normal;font-size:13.33px;font-style:normal;font-variant:norm=
al;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!imp=
ortant;white-space:pre;float:none;background-color:transparent"><font face=
=3D"courier new,monospace">template&lt;typename Allocator=3DAlloc&gt;<br>st=
ruct cool_boy </font></span></span></div><div><span style=3D"text-align:lef=
t;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:no=
rmal;font-size:13px;font-variant:normal;word-spacing:0px;display:inline!imp=
ortant;white-space:normal;float:none;background-color:transparent"><span st=
yle=3D"text-align:left;color:rgb(0,0,0);text-transform:none;text-indent:0px=
;letter-spacing:normal;font-size:13.33px;font-style:normal;font-variant:nor=
mal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!im=
portant;white-space:pre;float:none;background-color:transparent"><font face=
=3D"courier new,monospace">{<br>=C2=A0 [[no_unique_address]] Allocator allo=
c;<br>};</font></span></span></div><div><span style=3D"text-align:left;colo=
r:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;f=
ont-size:13px;font-variant:normal;word-spacing:0px;display:inline!important=
;white-space:normal;float:none;background-color:transparent"><span style=3D=
"text-align:left;color:rgb(0,0,0);text-transform:none;text-indent:0px;lette=
r-spacing:normal;font-size:13.33px;font-style:normal;font-variant:normal;fo=
nt-weight:400;text-decoration:none;word-spacing:0px;display:inline!importan=
t;white-space:pre;float:none;background-color:transparent"><font face=3D"co=
urier new"><br></font></span></span></div><div><span style=3D"text-align:le=
ft;color:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:n=
ormal;font-size:13px;font-variant:normal;word-spacing:0px;display:inline!im=
portant;white-space:normal;float:none;background-color:transparent"><span s=
tyle=3D"text-align:left;color:rgb(0,0,0);text-transform:none;text-indent:0p=
x;letter-spacing:normal;font-size:13.33px;font-style:normal;font-variant:no=
rmal;font-weight:400;text-decoration:none;word-spacing:0px;display:inline!i=
mportant;white-space:pre;float:none;background-color:transparent"><font fac=
e=3D"arial,sans-serif">This user code will fail to compile if the attr is i=
gnored.</font></span></span></div><div><span style=3D"text-align:left;color=
:rgb(34,34,34);text-transform:none;text-indent:0px;letter-spacing:normal;fo=
nt-size:13px;font-variant:normal;word-spacing:0px;display:inline!important;=
white-space:normal;float:none;background-color:transparent"><span style=3D"=
text-align:left;color:rgb(0,0,0);text-transform:none;text-indent:0px;letter=
-spacing:normal;font-size:13.33px;font-style:normal;font-variant:normal;fon=
t-weight:400;text-decoration:none;word-spacing:0px;display:inline!important=
;white-space:pre;float:none;background-color:transparent"><br></span></span=
></div><div><font face=3D"courier new,monospace">struct innocent_use<br>{<b=
r>=C2=A0 template&lt;class Cool, template =3D std::enable_if_t&lt;std::is_<=
wbr>empty_v&lt;Cool&gt;&gt;&gt;<br>=C2=A0 innocent_use(Cool&amp;&amp;) { }<=
br>};</font></div><div><font face=3D"courier new"><br></font></div><div><fo=
nt face=3D"courier new"><span style=3D"display:inline!important;float:none;=
background-color:transparent;color:rgb(34,34,34);font-family:courier new,mo=
nospace;font-size:13px;font-style:normal;font-variant:normal;font-weight:40=
0;letter-spacing:normal;text-align:left;text-decoration:none;text-indent:0p=
x;text-transform:none;white-space:normal;word-spacing:0px">innocent_use use=
{<span style=3D"background-color:transparent;border-bottom-color:rgb(0,0,0)=
;border-bottom-style:none;border-bottom-width:0px;border-left-color:rgb(0,0=
,0);border-left-style:none;border-left-width:0px;border-right-color:rgb(0,0=
,0);border-right-style:none;border-right-width:0px;border-top-color:rgb(0,0=
,0);border-top-style:none;border-top-width:0px;color:rgb(0,0,0);display:inl=
ine;float:none;font-family:courier new,monospace;font-size:13.33px;font-sty=
le:normal;font-variant:normal;font-weight:400;letter-spacing:normal;margin-=
bottom:0px;margin-left:0px;margin-right:0px;margin-top:0px;padding-bottom:0=
px;padding-left:0px;padding-right:0px;padding-top:0px;text-align:left;text-=
decoration:none;text-indent:0px;text-transform:none;white-space:pre;word-sp=
acing:0px">cool_boy{}</span>};</span></font></div><div></div><div><br></div=
><div>&quot;Or worse&quot; if another overload is present.=C2=A0</div><div>=
<font face=3D"courier new" color=3D"#007670" size=3D"2"><br></font></div><d=
iv><font face=3D"courier new" color=3D"#000111" size=3D"2"><br></font></div=
></div></blockquote><div>=C2=A0</div><div>Of corse, this why I said couple =
lines before &quot;should only affect size and address of member, nothing m=
ore&quot;. <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/91e1487d-aff5-4b35-835c-58d71546572b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91e1487d-aff5-4b35-835c-58d71546572b=
%40isocpp.org</a>.<br />

------=_Part_27824_1411240351.1514570459183--

------=_Part_27823_679545475.1514570459183--

.

------=_Part_28030_1218940748.1514575287595
Content-Type: multipart/alternative;
 boundary="----=_Part_28031_1932426486.1514575287595"

------=_Part_28031_1932426486.1514575287595
Content-Type: text/plain; charset="UTF-8"



On Friday, December 29, 2017 at 8:00:59 PM UTC+2, Marcin Jaczewski wrote:
>
>
>
> On Friday, December 29, 2017 at 9:26:39 AM UTC+1, mihailn...@gmail.com
> wrote:
>>
>> ...
>>
>>> ...
>>>
>> Of corse, this why I said couple lines before "should only affect size
> and address of member, nothing more".
>

But if it affects the size we are back at were we started, I believe. You
can imagine a SFINAE which fails if an object is bigger the some size.

And BTW isn't the attr affecting just that (and only that) already?

On related note, IIRC, we don't have [[pack]] for pretty much the same
reasons.

--
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/37abdf41-d3af-4020-9555-0241b7eb9ee1%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, December 29, 2017 at 8:00:59 PM UTC+2, =
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 di=
r=3D"ltr"><br><br>On Friday, December 29, 2017 at 9:26:39 AM UTC+1, <a>miha=
iln...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>...=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr"><div>...</div></div></blockquote></div></blockquote><div>Of cors=
e, this why I said couple lines before &quot;should only affect size and ad=
dress of member, nothing more&quot;. <br></div></div></blockquote><div><br>=
</div><div>But if it affects the size we are back at were we started, I bel=
ieve. You can imagine a SFINAE which fails if an object is bigger the some =
size. =C2=A0</div><div><br></div><div>And BTW isn&#39;t the attr affecting =
just that (and only that) already?=C2=A0</div><div><br></div><div>On relate=
d note, IIRC, we don&#39;t have [[pack]] for pretty much the same reasons.<=
/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/37abdf41-d3af-4020-9555-0241b7eb9ee1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/37abdf41-d3af-4020-9555-0241b7eb9ee1=
%40isocpp.org</a>.<br />

------=_Part_28031_1932426486.1514575287595--

------=_Part_28030_1218940748.1514575287595--

.

------=_Part_27897_316769567.1514576963299
Content-Type: multipart/alternative;
 boundary="----=_Part_27898_689926293.1514576963299"

------=_Part_27898_689926293.1514576963299
Content-Type: text/plain; charset="UTF-8"



On Friday, December 29, 2017 at 8:21:27 PM UTC+1, mihailn...@gmail.com
wrote:
>
>
>
> On Friday, December 29, 2017 at 8:00:59 PM UTC+2, Marcin Jaczewski wrote:
>>
>>
>>
>> On Friday, December 29, 2017 at 9:26:39 AM UTC+1, mihailn...@gmail.com
>> wrote:
>>>
>>> ...
>>>
>>>> ...
>>>>
>>> Of corse, this why I said couple lines before "should only affect size
>> and address of member, nothing more".
>>
>
> But if it affects the size we are back at were we started, I believe. You
> can imagine a SFINAE which fails if an object is bigger the some size.
>
> And BTW isn't the attr affecting just that (and only that) already?
>
> On related note, IIRC, we don't have [[pack]] for pretty much the same
> reasons.
>

But then this SFINAE test could fail on different compiler or architecture.
Is size of `std::string` standardized? Even size of `int` is defined as
range of allowed values not fixed value.
I think this attribute could work on premise that truly portable code
should not prejudge size of any object. But again this could work only in
very specific cases (not standard layout types) because we will again have
`std::is_empty` case.

--
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/ef93a424-900f-4541-a544-33e3950feccc%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, December 29, 2017 at 8:21:27 PM UTC+1, =
mihailn...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><br>On Friday, December 29, 2017 at 8:00:59 PM UTC+2, Mar=
cin Jaczewski wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><br><br>On Friday, December 29, 2017 at 9:26:39 AM UTC+1, <a>mihailn...@g=
mail.com</a> 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"=
><div>...=C2=A0</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"lt=
r"><div>...</div></div></blockquote></div></blockquote><div>Of corse, this =
why I said couple lines before &quot;should only affect size and address of=
 member, nothing more&quot;. <br></div></div></blockquote><div><br></div><d=
iv>But if it affects the size we are back at were we started, I believe. Yo=
u can imagine a SFINAE which fails if an object is bigger the some size. =
=C2=A0</div><div><br></div><div>And BTW isn&#39;t the attr affecting just t=
hat (and only that) already?=C2=A0</div><div><br></div><div>On related note=
, IIRC, we don&#39;t have [[pack]] for pretty much the same reasons.</div><=
/div></blockquote><div>=C2=A0</div><div>But then this SFINAE test could fai=
l on different compiler or architecture. Is size of `std::string` standardi=
zed? Even size of `int` is defined as range of allowed values not fixed val=
ue.</div><div>I think this attribute could work on premise that truly porta=
ble code should not prejudge size of any object. But again this could work =
only in very specific cases (not standard layout types) because we will aga=
in have `std::is_empty` case.<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/ef93a424-900f-4541-a544-33e3950feccc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ef93a424-900f-4541-a544-33e3950feccc=
%40isocpp.org</a>.<br />

------=_Part_27898_689926293.1514576963299--

------=_Part_27897_316769567.1514576963299--

.