------=_Part_18743_2133865005.1514295981992
Content-Type: multipart/alternative;
 boundary="----=_Part_18744_1063934103.1514295981992"

------=_Part_18744_1063934103.1514295981992
Content-Type: text/plain; charset="UTF-8"

Given that the copy and move constructors of both std::pair and std::tuple
are defaulted, why shouldn't we enforce the same for their respective
assignment operators? It seems strange that assigning these types would
invoke non-trivial work compared to just copy constructing them, and as a
result of this difference, currently both types are not considered
trivially copyable.

Based on an old discussion
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/PUZ9WUr2AOU>,
it seems that this discrepancy in the requirement caused some compilers to
make std::pair<scalar> trivially copyable while others don't. Furthermore,
someone on StackOverflow hacked up an implementation
<https://stackoverflow.com/questions/39229459> for std::tuple that was
trivially copyable. It would be nice if future proposals can provide some
potential guarantees on this matter.

--
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/ceb89ead-99c9-41fc-a40e-876eac97a6f1%40isocpp.org.

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

<div dir=3D"ltr"><div>Given that the copy and move constructors of both std=
::pair and std::tuple are defaulted, why shouldn&#39;t we enforce the same =
for their respective assignment operators? It seems strange that assigning =
these types would invoke non-trivial work compared to just copy constructin=
g them, and as a result of this difference, currently both types are not co=
nsidered trivially copyable.</div><div><br></div>Based on an old <a href=3D=
"https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/PUZ9WU=
r2AOU">discussion</a>, it seems that this discrepancy in the requirement ca=
used some compilers to make std::pair&lt;scalar&gt; trivially copyable whil=
e others don&#39;t. Furthermore, someone on StackOverflow=C2=A0<a href=3D"h=
ttps://stackoverflow.com/questions/39229459">hacked up an implementation</a=
> for std::tuple that was trivially copyable. It would be nice if future pr=
oposals can provide some potential guarantees on this matter.</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/ceb89ead-99c9-41fc-a40e-876eac97a6f1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ceb89ead-99c9-41fc-a40e-876eac97a6f1=
%40isocpp.org</a>.<br />

------=_Part_18744_1063934103.1514295981992--

------=_Part_18743_2133865005.1514295981992--

.

On 26 December 2017 at 15:46, mrpi via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> Given that the copy and move constructors of both std::pair and std::tuple
> are defaulted, why shouldn't we enforce the same for their respective
> assignment operators? It seems strange that assigning these types would
> invoke non-trivial work compared to just copy constructing them, and as a
> result of this difference, currently both types are not considered trivially
> copyable.
>
> Based on an old discussion, it seems that this discrepancy in the
> requirement caused some compilers to make std::pair<scalar> trivially
> copyable while others don't. Furthermore, someone on StackOverflow hacked up
> an implementation for std::tuple that was trivially copyable. It would be
> nice if future proposals can provide some potential guarantees on this
> matter.

The assignment operators need to be user-provided for reference
elements. Both pair and tuple can be made
conditionally trivial when there are no reference elements, but doing
so is an ABI break.

--
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/CAFk2RUab3JK%3DU0vrxZ6d0r3vaY%3D-64usQyPHCOf9%3DV1v-T%3DXTA%40mail.gmail.com.

.

------=_Part_18603_155550226.1514300525168
Content-Type: multipart/alternative;
 boundary="----=_Part_18604_1016768534.1514300525168"

------=_Part_18604_1016768534.1514300525168
Content-Type: text/plain; charset="UTF-8"

Sorry, I might not be understanding it correctly, but in what way would it
be an ABI break, given that reference types are not trivially copyable
anyways?

On Tuesday, December 26, 2017 at 5:50:57 AM UTC-8, Ville Voutilainen wrote:
>
> On 26 December 2017 at 15:46, mrpi via ISO C++ Standard - Future
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
> > Given that the copy and move constructors of both std::pair and
> std::tuple
> > are defaulted, why shouldn't we enforce the same for their respective
> > assignment operators? It seems strange that assigning these types would
> > invoke non-trivial work compared to just copy constructing them, and as
> a
> > result of this difference, currently both types are not considered
> trivially
> > copyable.
> >
> > Based on an old discussion, it seems that this discrepancy in the
> > requirement caused some compilers to make std::pair<scalar> trivially
> > copyable while others don't. Furthermore, someone on StackOverflow
> hacked up
> > an implementation for std::tuple that was trivially copyable. It would
> be
> > nice if future proposals can provide some potential guarantees on this
> > matter.
>
> The assignment operators need to be user-provided for reference
> elements. Both pair and tuple can be made
> conditionally trivial when there are no reference elements, but doing
> so is an ABI break.
>

--
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/4110e47f-a021-4ccc-9e03-53e4ebdb8c21%40isocpp.org.

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

<div dir=3D"ltr">Sorry, I might not be understanding it correctly, but in w=
hat way would it be an ABI break, given that reference types are not trivia=
lly copyable anyways?<br><br>On Tuesday, December 26, 2017 at 5:50:57 AM UT=
C-8, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n 26 December 2017 at 15:46, mrpi via ISO C++ Standard - Future
<br>Proposals &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"USJn2ReVCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">std-pr...@isocpp.org</a>&gt; wrote:
<br>&gt; Given that the copy and move constructors of both std::pair and st=
d::tuple
<br>&gt; are defaulted, why shouldn&#39;t we enforce the same for their res=
pective
<br>&gt; assignment operators? It seems strange that assigning these types =
would
<br>&gt; invoke non-trivial work compared to just copy constructing them, a=
nd as a
<br>&gt; result of this difference, currently both types are not considered=
 trivially
<br>&gt; copyable.
<br>&gt;
<br>&gt; Based on an old discussion, it seems that this discrepancy in the
<br>&gt; requirement caused some compilers to make std::pair&lt;scalar&gt; =
trivially
<br>&gt; copyable while others don&#39;t. Furthermore, someone on StackOver=
flow hacked up
<br>&gt; an implementation for std::tuple that was trivially copyable. It w=
ould be
<br>&gt; nice if future proposals can provide some potential guarantees on =
this
<br>&gt; matter.
<br>
<br>The assignment operators need to be user-provided for reference
<br>elements. Both pair and tuple can be made
<br>conditionally trivial when there are no reference elements, but doing
<br>so is an ABI break.
<br></blockquote></div>

<p></p>

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

------=_Part_18604_1016768534.1514300525168--

------=_Part_18603_155550226.1514300525168--

.

On ter=C3=A7a-feira, 26 de dezembro de 2017 13:02:05 -02 mrpi via ISO C++ S=
tandard=20
- Future Proposals wrote:
> Sorry, I might not be understanding it correctly, but in what way would i=
t
> be an ABI break, given that reference types are not trivially copyable
> anyways?

Changing a type from trivially copyable to not, or vice-versa, is the ABI=
=20
change.

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

--=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/4605434.q3o9RnjlYE%40tjmaciei-mobl1.

.

------=_Part_19163_695658782.1514313427800
Content-Type: multipart/alternative;
 boundary="----=_Part_19164_1830722837.1514313427800"

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

How would it be an ABI break/change if the standard never specified if it=
=20
was trivially copyable or not? In the first place, the discrepancy between=
=20
different compilers on whether these two classes are trivially copyable is=
=20
because of such a lack of clarity on that part, so what I'm asking for is a=
=20
proposal to make them clearly use default assignment operators.

Furthermore, I can't see how changing a type from being not trivially=20
copyable to being trivially copyable would be a problem. If so, then the=20
entire recent discussion about optionals and variants=20
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/A0EgNQe=
VR44> would=20
be moot (for which those classes are also currently not guaranteed to use=
=20
default copy/move constructors/assignments and not guaranteed trivially=20
copyable).

On Tuesday, December 26, 2017 at 10:11:20 AM UTC-8, Thiago Macieira wrote:
>
> On ter=C3=A7a-feira, 26 de dezembro de 2017 13:02:05 -02 mrpi via ISO C++=
=20
> Standard=20
> - Future Proposals wrote:=20
> > Sorry, I might not be understanding it correctly, but in what way would=
=20
> it=20
> > be an ABI break, given that reference types are not trivially copyable=
=20
> > anyways?=20
>
> Changing a type from trivially copyable to not, or vice-versa, is the ABI=
=20
> change.=20
>
> --=20
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20
>    Software Architect - Intel Open Source Technology Center=20
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5300cf40-f7db-4eb6-ad36-4742855124ae%40isocpp.or=
g.

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

<div dir=3D"ltr">How would it be an ABI break/change if the standard never =
specified if it was trivially copyable or not? In the first place, the disc=
repancy between different compilers on whether these two classes are trivia=
lly copyable is because of such a lack of clarity on that part, so what I&#=
39;m asking for is a proposal to make them clearly use default assignment o=
perators.<div><br></div><div><div>Furthermore, I can&#39;t see how changing=
 a type from being not trivially copyable to being trivially copyable would=
 be a problem. If so, then the entire recent discussion about <a href=3D"ht=
tps://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/A0EgNQeVR4=
4">optionals and variants</a>=C2=A0would be moot (for which those classes a=
re also currently not guaranteed to use default copy/move constructors/assi=
gnments and not guaranteed trivially copyable).<br><div><br>On Tuesday, Dec=
ember 26, 2017 at 10:11:20 AM UTC-8, Thiago Macieira wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;">On ter=C3=A7a-feira, 26 de dezembro de 2017 13=
:02:05 -02 mrpi via ISO C++ Standard=20
<br>- Future Proposals wrote:
<br>&gt; Sorry, I might not be understanding it correctly, but in what way =
would it
<br>&gt; be an ABI break, given that reference types are not trivially copy=
able
<br>&gt; anyways?
<br>
<br>Changing a type from trivially copyable to not, or vice-versa, is the A=
BI=20
<br>change.
<br>
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x3dD\x26sntz\x3d1\x26usg\=
x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fmacieira.info\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEswDUBNCNanbu7euhqLn_62FW8ag&#39;;return t=
rue;">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.=
com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH=
GRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;" onclick=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fkde.org\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA&#39;;return true;">kde.org</a=
>
<br>=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center
<br>
<br></blockquote></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/5300cf40-f7db-4eb6-ad36-4742855124ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5300cf40-f7db-4eb6-ad36-4742855124ae=
%40isocpp.org</a>.<br />

------=_Part_19164_1830722837.1514313427800--

------=_Part_19163_695658782.1514313427800--

.

On 26 December 2017 at 20:37, mrpi via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> How would it be an ABI break/change if the standard never specified if it
> was trivially copyable or not? In the first place, the discrepancy between


The point is that tuple<int> is not a trivially copyable type in
libstdc++ today. Making it trivially copyable
would be an ABI break.

--
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/CAFk2RUaPfYJCxWTB54eFNBw559Av6XKaLUciixB77by3uLb6eQ%40mail.gmail.com.

.

------=_Part_19128_1057704000.1514317895830
Content-Type: multipart/alternative;
 boundary="----=_Part_19129_1020130931.1514317895830"

------=_Part_19129_1020130931.1514317895830
Content-Type: text/plain; charset="UTF-8"

Doesn't the same argument about optionals and variants
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/A0EgNQeVR44> apply?
Just recently std::optional and std::variant weren't yet made trivially
copyable (nor have any recent draft of the standard accepted it yet). What
I'm asking about is doing the same for std::pair and std::tuple.

And furthermore, what sort of problems would pop up from enforcing
std::tuple<int> to be trivially copyable?

On Tuesday, December 26, 2017 at 11:36:01 AM UTC-8, Ville Voutilainen wrote:
>
> On 26 December 2017 at 20:37, mrpi via ISO C++ Standard - Future
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
> > How would it be an ABI break/change if the standard never specified if
> it
> > was trivially copyable or not? In the first place, the discrepancy
> between
>
>
> The point is that tuple<int> is not a trivially copyable type in
> libstdc++ today. Making it trivially copyable
> would be an ABI break.
>

--
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/fcf44c66-1097-4242-a265-1629aaf24ebb%40isocpp.org.

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

<div dir=3D"ltr">Doesn&#39;t the same argument about=C2=A0<a href=3D"https:=
//groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/A0EgNQeVR44" t=
arget=3D"_blank" rel=3D"nofollow" style=3D"cursor: pointer;">optionals and =
variants</a>=C2=A0apply? Just recently std::optional and std::variant weren=
&#39;t yet made trivially copyable (nor have any recent draft of the standa=
rd accepted it yet). What I&#39;m asking about is doing the same for std::p=
air and std::tuple.<div><br></div><div>And furthermore, what sort of proble=
ms would pop up from enforcing std::tuple&lt;int&gt; to be trivially copyab=
le?<br><br>On Tuesday, December 26, 2017 at 11:36:01 AM UTC-8, Ville Voutil=
ainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 26 December 201=
7 at 20:37, mrpi via ISO C++ Standard - Future
<br>Proposals &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"GilBa-ynCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">std-pr...@isocpp.org</a>&gt; wrote:
<br>&gt; How would it be an ABI break/change if the standard never specifie=
d if it
<br>&gt; was trivially copyable or not? In the first place, the discrepancy=
 between
<br>
<br>
<br>The point is that tuple&lt;int&gt; is not a trivially copyable type in
<br>libstdc++ today. Making it trivially copyable
<br>would be an ABI break.
<br></blockquote></div></div>

<p></p>

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

------=_Part_19129_1020130931.1514317895830--

------=_Part_19128_1057704000.1514317895830--

.

On 26 December 2017 at 21:51, mrpi via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
> Doesn't the same argument about optionals and variants apply? Just recently
> std::optional and std::variant weren't yet made trivially copyable (nor have
> any recent draft of the standard accepted it yet). What I'm asking about is
> doing the same for std::pair and std::tuple.

The difference is that optional and variant were introduced in C++17,
and are still considered
experimental by (some) implementations. Both tuple and pair have been
there since C++11 or before.

> And furthermore, what sort of problems would pop up from enforcing
> std::tuple<int> to be trivially copyable?


No other problems besides the ABI break, I think. Implementation-wise
there's nothing The Elf or his
Mighty Maintainer could not do, and the same applies to other
implementations and their authors;
making such types conditionally trivial is not particularly hard. The
warts arise because the C++11
types weren't specified or necessarily known how to write in
fully-constexpr (constexpr was enhanced
in C++14) or fully-triviality-reflecting fashion, and changing that,
while doable in a pure C++17 environment,
is not always so straightforward when C++11 (and ABI) compatibility is
a concern.

--
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/CAFk2RUY3XQiLzsSTiZ6QECf7EK%3DyEoq%2B3JGA05783AgbqHVMOg%40mail.gmail.com.

.

------=_Part_19781_629448826.1514323990603
Content-Type: multipart/alternative;
 boundary="----=_Part_19782_119203547.1514323990603"

------=_Part_19782_119203547.1514323990603
Content-Type: text/plain; charset="UTF-8"

Could we possibly consider it a defect to be fixed? There never was a good
reason other than history for them not being guaranteed trivially
conditional when templated on trivially copyable types. In the same manner
as how the definition of "trivially copyable" has been retroactively
changed for the C++11 standard post-C++14 (e.g. that the destructor must
not be deleted) to clear up the difference in behavior of
std::is_trivially_copyable between MSVC and lib(std)?c++, couldn't we
consider it a fix to clear up this ambiguity? After all, even now we have
slight differences (MSVC has std::pair<int, int> as trivially copyable).

Along with the changes to std::optional and std::variant, we can also make
this a trend in pushing for types to be more trivial/trivially copyable
wherever possible.

On Tuesday, December 26, 2017 at 12:11:21 PM UTC-8, Ville Voutilainen wrote:
>
> On 26 December 2017 at 21:51, mrpi via ISO C++ Standard - Future
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
> > Doesn't the same argument about optionals and variants apply? Just
> recently
> > std::optional and std::variant weren't yet made trivially copyable (nor
> have
> > any recent draft of the standard accepted it yet). What I'm asking about
> is
> > doing the same for std::pair and std::tuple.
>
> The difference is that optional and variant were introduced in C++17,
> and are still considered
> experimental by (some) implementations. Both tuple and pair have been
> there since C++11 or before.
>
> > And furthermore, what sort of problems would pop up from enforcing
> > std::tuple<int> to be trivially copyable?
>
>
> No other problems besides the ABI break, I think. Implementation-wise
> there's nothing The Elf or his
> Mighty Maintainer could not do, and the same applies to other
> implementations and their authors;
> making such types conditionally trivial is not particularly hard. The
> warts arise because the C++11
> types weren't specified or necessarily known how to write in
> fully-constexpr (constexpr was enhanced
> in C++14) or fully-triviality-reflecting fashion, and changing that,
> while doable in a pure C++17 environment,
> is not always so straightforward when C++11 (and ABI) compatibility is
> a concern.
>

--
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/9d1e799d-b127-457f-9bd2-c815bd914d15%40isocpp.org.

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

<div dir=3D"ltr">Could we possibly consider it a defect to be fixed? There =
never was a good reason other than history for them not being guaranteed tr=
ivially conditional when templated on trivially copyable types. In the same=
 manner as how the definition of &quot;trivially copyable&quot; has been re=
troactively changed for the C++11 standard post-C++14 (e.g. that the destru=
ctor must not be deleted) to clear up the difference in behavior of std::is=
_trivially_copyable between MSVC and lib(std)?c++, couldn&#39;t we consider=
 it a fix to clear up this ambiguity? After all, even now we have slight di=
fferences (MSVC has std::pair&lt;int, int&gt; as trivially copyable).<div><=
br></div><div>Along with the changes to std::optional and std::variant, we =
can also make this a trend in pushing for types to be more trivial/triviall=
y copyable wherever possible.<br><br>On Tuesday, December 26, 2017 at 12:11=
:21 PM UTC-8, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">On 26 December 2017 at 21:51, mrpi via ISO C++ Standard - Future
<br>Proposals &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"5JKzHtqpCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">std-pr...@isocpp.org</a>&gt; wrote:
<br>&gt; Doesn&#39;t the same argument about optionals and variants apply? =
Just recently
<br>&gt; std::optional and std::variant weren&#39;t yet made trivially copy=
able (nor have
<br>&gt; any recent draft of the standard accepted it yet). What I&#39;m as=
king about is
<br>&gt; doing the same for std::pair and std::tuple.
<br>
<br>The difference is that optional and variant were introduced in C++17,
<br>and are still considered
<br>experimental by (some) implementations. Both tuple and pair have been
<br>there since C++11 or before.
<br>
<br>&gt; And furthermore, what sort of problems would pop up from enforcing
<br>&gt; std::tuple&lt;int&gt; to be trivially copyable?
<br>
<br>
<br>No other problems besides the ABI break, I think. Implementation-wise
<br>there&#39;s nothing The Elf or his
<br>Mighty Maintainer could not do, and the same applies to other
<br>implementations and their authors;
<br>making such types conditionally trivial is not particularly hard. The
<br>warts arise because the C++11
<br>types weren&#39;t specified or necessarily known how to write in
<br>fully-constexpr (constexpr was enhanced
<br>in C++14) or fully-triviality-reflecting fashion, and changing that,
<br>while doable in a pure C++17 environment,
<br>is not always so straightforward when C++11 (and ABI) compatibility is
<br>a concern.
<br></blockquote></div></div>

<p></p>

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

------=_Part_19782_119203547.1514323990603--

------=_Part_19781_629448826.1514323990603--

.

------=_Part_19427_464236254.1514325280914
Content-Type: multipart/alternative;
 boundary="----=_Part_19428_795676701.1514325280914"

------=_Part_19428_795676701.1514325280914
Content-Type: text/plain; charset="UTF-8"

On Tuesday, December 26, 2017 at 4:33:10 PM UTC-5, mr...@google.com wrote:
>
> Could we possibly consider it a defect to be fixed?
>

A defect fix from 6 years ago which requires a possibly ABI-breaking change
to implementations? I rather doubt it.

The changes to `std::basic_string` which prevent COW implementations were
not considered "defects", even though I would certainly consider COW
implementations "quality" in the wrong direction in most cases. They were a
formal part of C++11.

Making such a change as a defect fix is not going to make implementers more
likely to make those ABI-breaking changes.

There never was a good reason other than history for them not being
> guaranteed trivially conditional when templated on trivially copyable
> types. In the same manner as how the definition of "trivially copyable" has
> been retroactively changed for the C++11 standard post-C++14 (e.g. that the
> destructor must not be deleted) to clear up the difference in behavior of
> std::is_trivially_copyable between MSVC and lib(std)?c++,
>

No, that's different. It was never the intent to make types with deleted
destructors be trivially copyable. That was merely a mistake; fixing it had
nothing to do with library variance.

Also, that defect was first reported in 2013; it just took a while for them
to work out a fix for it. Lastly, making such a change does not require
breaking the ABI of any library implementation.

couldn't we consider it a fix to clear up this ambiguity? After all, even
> now we have slight differences (MSVC has std::pair<int, int> as trivially
> copyable).
>

Differences between implementations are expected; that's (part of) why we
have different implementations instead of just pointing at a codebase and
saying, "that's the standard".

Along with the changes to std::optional and std::variant, we can also make
> this a trend in pushing for types to be more trivial/trivially copyable
> wherever possible.
>

--
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/e651d733-db30-4097-a7d4-d1e713aef120%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, December 26, 2017 at 4:33:10 PM UTC-5, mr...@g=
oogle.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"lt=
r">Could we possibly consider it a defect to be fixed?</div></blockquote><d=
iv><br></div><div>A defect fix from 6 years ago which requires a possibly A=
BI-breaking change to implementations? I rather doubt it.</div><div><br></d=
iv><div>The changes to `std::basic_string` which prevent COW implementation=
s were not considered &quot;defects&quot;, even though I would certainly co=
nsider COW implementations &quot;quality&quot; in the wrong direction in mo=
st cases. They were a formal part of C++11.</div><div><br></div><div>Making=
 such a change as a defect fix is not going to make implementers more likel=
y to make those ABI-breaking changes.</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">There never was a good reason =
other than history for them not being guaranteed trivially conditional when=
 templated on trivially copyable types. In the same manner as how the defin=
ition of &quot;trivially copyable&quot; has been retroactively changed for =
the C++11 standard post-C++14 (e.g. that the destructor must not be deleted=
) to clear up the difference in behavior of std::is_trivially_copyable betw=
een MSVC and lib(std)?c++,</div></blockquote><div><br></div><div>No, that&#=
39;s different. It was never the intent to make types with deleted destruct=
ors be trivially copyable. That was merely a mistake; fixing it had nothing=
 to do with library variance.</div><div><br></div><div>Also, that defect wa=
s first reported in 2013; it just took a while for them to work out a fix f=
or it. Lastly, making such a change does not require breaking the ABI of an=
y library implementation.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">couldn&#39;t we consider it a fix to clear=
 up this ambiguity? After all, even now we have slight differences (MSVC ha=
s std::pair&lt;int, int&gt; as trivially copyable).</div></blockquote><div>=
<br></div><div>Differences between implementations are expected; that&#39;s=
 (part of) why we have different implementations instead of just pointing a=
t a codebase and saying, &quot;that&#39;s the standard&quot;.</div><div><br=
></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>A=
long with the changes to std::optional and std::variant, we can also make t=
his a trend in pushing for types to be more trivial/trivially copyable wher=
ever possible.<br></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/e651d733-db30-4097-a7d4-d1e713aef120%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e651d733-db30-4097-a7d4-d1e713aef120=
%40isocpp.org</a>.<br />

------=_Part_19428_795676701.1514325280914--

------=_Part_19427_464236254.1514325280914--

.

On ter=C3=A7a-feira, 26 de dezembro de 2017 19:33:10 -02 mrpi via ISO C++ S=
tandard=20
- Future Proposals wrote:
> Could we possibly consider it a defect to be fixed?

Why? How in the world does this change affect you?

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

--=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/9350361.rvT4A9TCtj%40tjmaciei-mobl1.

.

------=_Part_19434_1842324615.1514332072916
Content-Type: multipart/alternative;
 boundary="----=_Part_19435_1713699576.1514332072916"

------=_Part_19435_1713699576.1514332072916
Content-Type: text/plain; charset="UTF-8"


>
> The changes to `std::basic_string` which prevent COW implementations were
> not considered "defects", even though I would certainly consider COW
> implementations "quality" in the wrong direction in most cases. They were a
> formal part of C++11.
>

Would the enforcement of preventing copy-on-write implementations for
std::basic_string be an ABI-breaking change? It certainly would change some
assumptions about performance in certain cases. Also, in the same way,
couldn't we consider the shift to enforcing default assignment operators
for std::pair and std::tuple be a quality improvement, given that it helps
in obtaining the transitivity of trivial copyability?

No, that's different. It was never the intent to make types with deleted
> destructors be trivially copyable. That was merely a mistake; fixing it had
> nothing to do with library variance.
>

>
Also, that defect was first reported in 2013; it just took a while for them
> to work out a fix for it. Lastly, making such a change does not require
> breaking the ABI of any library implementation.
>

Then what about the fact that each copy/move constructor/assignment could
be deleted and still maintain trivial copyability? Or the fact that at
least one of them must not be deleted? In the former case, due to the
wording of "non-trivial," MSVC implemented it as requiring all copy/move
constructors/assignments to be defined and defaulted, and the change in the
wording breaks that assumption. In the latter case, lib(std)?c++ was okay
with all of them being deleted, which is a far more severe breakage in that
class previously considered trivially copyable are no longer so after the
wording change.


> Why? How in the world does this change affect you?


There are some memory guarantees I want, in such a way that sizeof(type)
would be an accurate estimation of its memory usage. The property of
trivially copyable types in being memcpy-able is a perfect fit for deducing
the most general cases.

Other than that, it's a performance guarantee. Like pointed out in the old
discussion
<https://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/PUZ9WUr2AOU>, if
I have a std::vector<std::pair<int, int>>, I would like it to be as
efficient as std::vector<MyPairOfInts>, where MyPairOfInts is a trivially
copyable struct containing two ints. It also means that copying such
trivially copyable types around can use some optimized memcpy-like function
instead of copying over each internal field.

On Tuesday, December 26, 2017 at 1:54:41 PM UTC-8, Nicol Bolas wrote:
>
> On Tuesday, December 26, 2017 at 4:33:10 PM UTC-5, mr...@google.com wrote:
>>
>> Could we possibly consider it a defect to be fixed?
>>
>
> A defect fix from 6 years ago which requires a possibly ABI-breaking
> change to implementations? I rather doubt it.
>
> The changes to `std::basic_string` which prevent COW implementations were
> not considered "defects", even though I would certainly consider COW
> implementations "quality" in the wrong direction in most cases. They were a
> formal part of C++11.
>
> Making such a change as a defect fix is not going to make implementers
> more likely to make those ABI-breaking changes.
>
> There never was a good reason other than history for them not being
>> guaranteed trivially conditional when templated on trivially copyable
>> types. In the same manner as how the definition of "trivially copyable" has
>> been retroactively changed for the C++11 standard post-C++14 (e.g. that the
>> destructor must not be deleted) to clear up the difference in behavior of
>> std::is_trivially_copyable between MSVC and lib(std)?c++,
>>
>
> No, that's different. It was never the intent to make types with deleted
> destructors be trivially copyable. That was merely a mistake; fixing it had
> nothing to do with library variance.
>
> Also, that defect was first reported in 2013; it just took a while for
> them to work out a fix for it. Lastly, making such a change does not
> require breaking the ABI of any library implementation.
>
> couldn't we consider it a fix to clear up this ambiguity? After all, even
>> now we have slight differences (MSVC has std::pair<int, int> as trivially
>> copyable).
>>
>
> Differences between implementations are expected; that's (part of) why we
> have different implementations instead of just pointing at a codebase and
> saying, "that's the standard".
>
> Along with the changes to std::optional and std::variant, we can also make
>> this a trend in pushing for types to be more trivial/trivially copyable
>> wherever possible.
>>
>

--
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/39606695-51a7-46d6-874d-0ddb99fabf0e%40isocpp.org.

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

<div dir=3D"ltr"><div><div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;"><div dir=3D"ltr">The changes to `std::basic_string` which prevent=
 COW implementations were not considered &quot;defects&quot;, even though I=
 would certainly consider COW implementations &quot;quality&quot; in the wr=
ong direction in most cases. They were a formal part of C++11.</div></block=
quote><div><br></div><div>Would the enforcement of preventing copy-on-write=
 implementations for std::basic_string be an ABI-breaking change? It certai=
nly would change some assumptions about performance in certain cases. Also,=
 in the same way, couldn&#39;t we consider the shift to enforcing default a=
ssignment operators for std::pair and std::tuple be a quality improvement, =
given that it helps in obtaining the transitivity of trivial copyability?=
=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le=
ft: 1ex;"><div dir=3D"ltr">No, that&#39;s different. It was never the inten=
t to make types with deleted destructors be trivially copyable. That was me=
rely a mistake; fixing it had nothing to do with library variance.=C2=A0</d=
iv></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><=
div dir=3D"ltr">=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Also, that defect =
was first reported in 2013; it just took a while for them to work out a fix=
 for it. Lastly, making such a change does not require breaking the ABI of =
any library implementation.</div></div></blockquote><div>=C2=A0</div><div>T=
hen what about the fact that each copy/move constructor/assignment could be=
 deleted and still maintain trivial copyability? Or the fact that at least =
one of them must not be deleted? In the former case, due to the wording of =
&quot;non-trivial,&quot; MSVC implemented it as requiring all copy/move con=
structors/assignments to be defined and defaulted, and the change in the wo=
rding breaks that assumption. In the latter case, lib(std)?c++ was okay wit=
h all of them being deleted, which is a far more severe breakage in that cl=
ass previously considered trivially copyable are no longer so after the wor=
ding change.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;"><div dir=3D"ltr"><div></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 2=
04, 204); padding-left: 1ex;"><div dir=3D"ltr"></div></blockquote></div></b=
lockquote></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">W=
hy? How in the world does this change affect you?=C2=A0</blockquote><div><b=
r></div><div>There are some memory guarantees I want, in such a way that si=
zeof(type) would be an accurate estimation of its memory usage. The propert=
y of trivially copyable types in being memcpy-able is a perfect fit for ded=
ucing the most general cases.</div><div><br></div><div>Other than that, it&=
#39;s a performance guarantee. Like pointed out in the=C2=A0<a href=3D"http=
s://groups.google.com/a/isocpp.org/forum/#!topic/std-discussion/PUZ9WUr2AOU=
" target=3D"_blank" rel=3D"nofollow" style=3D"cursor: pointer;">old discuss=
ion</a>,=C2=A0if I have a std::vector&lt;std::pair&lt;int, int&gt;&gt;, I w=
ould like it to be as efficient as std::vector&lt;MyPairOfInts&gt;, where M=
yPairOfInts is a trivially copyable struct containing two ints. It also mea=
ns that copying such trivially copyable types around can use some optimized=
 memcpy-like function instead of copying over each internal field.</div></d=
iv><br>On Tuesday, December 26, 2017 at 1:54:41 PM UTC-8, Nicol Bolas wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Tuesday, =
December 26, 2017 at 4:33:10 PM UTC-5, <a>mr...@google.com</a> wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Could we possibly consid=
er it a defect to be fixed?</div></blockquote><div><br></div><div>A defect =
fix from 6 years ago which requires a possibly ABI-breaking change to imple=
mentations? I rather doubt it.</div><div><br></div><div>The changes to `std=
::basic_string` which prevent COW implementations were not considered &quot=
;defects&quot;, even though I would certainly consider COW implementations =
&quot;quality&quot; in the wrong direction in most cases. They were a forma=
l part of C++11.</div><div><br></div><div>Making such a change as a defect =
fix is not going to make implementers more likely to make those ABI-breakin=
g changes.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">There never was a good reason other than history for them not =
being guaranteed trivially conditional when templated on trivially copyable=
 types. In the same manner as how the definition of &quot;trivially copyabl=
e&quot; has been retroactively changed for the C++11 standard post-C++14 (e=
..g. that the destructor must not be deleted) to clear up the difference in =
behavior of std::is_trivially_copyable between MSVC and lib(std)?c++,</div>=
</blockquote><div><br></div><div>No, that&#39;s different. It was never the=
 intent to make types with deleted destructors be trivially copyable. That =
was merely a mistake; fixing it had nothing to do with library variance.</d=
iv><div><br></div><div>Also, that defect was first reported in 2013; it jus=
t took a while for them to work out a fix for it. Lastly, making such a cha=
nge does not require breaking the ABI of any library implementation.</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">coul=
dn&#39;t we consider it a fix to clear up this ambiguity? After all, even n=
ow we have slight differences (MSVC has std::pair&lt;int, int&gt; as trivia=
lly copyable).</div></blockquote><div><br></div><div>Differences between im=
plementations are expected; that&#39;s (part of) why we have different impl=
ementations instead of just pointing at a codebase and saying, &quot;that&#=
39;s the standard&quot;.</div><div><br></div><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>Along with the changes to std::optional and=
 std::variant, we can also make this a trend in pushing for types to be mor=
e trivial/trivially copyable wherever possible.<br></div></div></blockquote=
></div></blockquote></div>

<p></p>

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

------=_Part_19435_1713699576.1514332072916--

------=_Part_19434_1842324615.1514332072916--

.

------=_Part_19669_316424259.1514334734996
Content-Type: multipart/alternative;
 boundary="----=_Part_19670_2120470870.1514334734996"

------=_Part_19670_2120470870.1514334734996
Content-Type: text/plain; charset="UTF-8"

On Tuesday, December 26, 2017 at 6:47:52 PM UTC-5, mr...@google.com wrote:
>
> The changes to `std::basic_string` which prevent COW implementations were
>> not considered "defects", even though I would certainly consider COW
>> implementations "quality" in the wrong direction in most cases. They were a
>> formal part of C++11.
>>
>
> Would the enforcement of preventing copy-on-write implementations for
> std::basic_string be an ABI-breaking change?
>

Almost certainly yes. I'm not an expert on COW string implementations, but
I'm not sure that it's reasonable for a COW `basic_string` to have the same
internal representation as a non-COW version. And even if they could, they
certainly wouldn't have the same ABI as an SSO-based `basic_string`, which
means that's an optimization you would be unable to provide.

It certainly would change some assumptions about performance in certain
> cases. Also, in the same way, couldn't we consider the shift to enforcing
> default assignment operators for std::pair and std::tuple be a quality
> improvement, given that it helps in obtaining the transitivity of trivial
> copyability?
>

But it would not be a* defect* change; that's what we're talking about. The
magnitude of such a change is such that it's not something that's
reasonable for a mere defect report & fix. It would have to be a genuine
feature of an actual language version, like forbidding COW strings.

No, that's different. It was never the intent to make types with deleted
>> destructors be trivially copyable. That was merely a mistake; fixing it had
>> nothing to do with library variance.
>>
>
>>
> Also, that defect was first reported in 2013; it just took a while for
>> them to work out a fix for it. Lastly, making such a change does not
>> require breaking the ABI of any library implementation.
>>
>
> Then what about the fact that each copy/move constructor/assignment could
> be deleted and still maintain trivial copyability? Or the fact that at
> least one of them must not be deleted? In the former case, due to the
> wording of "non-trivial," MSVC implemented it as requiring all copy/move
> constructors/assignments to be defined and defaulted, and the change in the
> wording breaks that assumption. In the latter case, lib(std)?c++ was okay
> with all of them being deleted, which is a far more severe breakage in that
> class previously considered trivially copyable are no longer so after the
> wording change.
>

None of those are ABI changes. Are you sure you have an understanding of
what an ABI change would be?

Also, the only classes which would lose trivial copyability under the new
wording are those that deleted their* destructors*. People generally don't
do that.

--
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/1ea1e6b6-321c-47b4-ba97-945daecf992f%40isocpp.org.

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

<div dir=3D"ltr">On Tuesday, December 26, 2017 at 6:47:52 PM UTC-5, mr...@g=
oogle.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"lt=
r"><div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr">The changes to `std::basic_string` which prevent COW implementations w=
ere not considered &quot;defects&quot;, even though I would certainly consi=
der COW implementations &quot;quality&quot; in the wrong direction in most =
cases. They were a formal part of C++11.</div></blockquote><div><br></div><=
div>Would the enforcement of preventing copy-on-write implementations for s=
td::basic_string be an ABI-breaking change?</div></div></div></div></blockq=
uote><div><br></div><div>Almost certainly yes. I&#39;m not an expert on COW=
 string implementations, but I&#39;m not sure that it&#39;s reasonable for =
a COW `basic_string` to have the same internal representation as a non-COW =
version. And even if they could, they certainly wouldn&#39;t have the same =
ABI as an SSO-based `basic_string`, which means that&#39;s an optimization =
you would be unable to provide.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div>It certainly would ch=
ange some assumptions about performance in certain cases. Also, in the same=
 way, couldn&#39;t we consider the shift to enforcing default assignment op=
erators for std::pair and std::tuple be a quality improvement, given that i=
t helps in obtaining the transitivity of trivial copyability?</div></div></=
div></div></blockquote><div><br></div><div>But it would not be a<i> defect<=
/i> change; that&#39;s what we&#39;re talking about. The magnitude of such =
a change is such that it&#39;s not something that&#39;s reasonable for a me=
re defect report &amp; fix. It would have to be a genuine feature of an act=
ual language version, like forbidding COW strings.</div><div><i></i><i></i>=
<br></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"><di=
v><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">N=
o, that&#39;s different. It was never the intent to make types with deleted=
 destructors be trivially copyable. That was merely a mistake; fixing it ha=
d nothing to do with library variance.=C2=A0</div></blockquote><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=C2=A0</div></blockq=
uote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v></div><div>Also, that defect was first reported in 2013; it just took a w=
hile for them to work out a fix for it. Lastly, making such a change does n=
ot require breaking the ABI of any library implementation.</div></div></blo=
ckquote><div><br></div><div>Then what about the fact that each copy/move co=
nstructor/assignment could be deleted and still maintain trivial copyabilit=
y? Or the fact that at least one of them must not be deleted? In the former=
 case, due to the wording of &quot;non-trivial,&quot; MSVC implemented it a=
s requiring all copy/move constructors/assignments to be defined and defaul=
ted, and the change in the wording breaks that assumption. In the latter ca=
se, lib(std)?c++ was okay with all of them being deleted, which is a far mo=
re severe breakage in that class previously considered trivially copyable a=
re no longer so after the wording change.</div></div></div></div></blockquo=
te><div><br></div><div>None of those are ABI changes. Are you sure you have=
 an understanding of what an ABI change would be?</div><div><br></div><div>=
Also, the only classes which would lose trivial copyability under the new w=
ording are those that deleted their<i> destructors</i>. People generally do=
n&#39;t do that.<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/1ea1e6b6-321c-47b4-ba97-945daecf992f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1ea1e6b6-321c-47b4-ba97-945daecf992f=
%40isocpp.org</a>.<br />

------=_Part_19670_2120470870.1514334734996--

------=_Part_19669_316424259.1514334734996--

.

------=_Part_19845_339820878.1514336317799
Content-Type: multipart/alternative;
 boundary="----=_Part_19846_379493373.1514336317799"

------=_Part_19846_379493373.1514336317799
Content-Type: text/plain; charset="UTF-8"


>
> But it would not be a* defect* change; that's what we're talking about.
> The magnitude of such a change is such that it's not something that's
> reasonable for a mere defect report & fix. It would have to be a genuine
> feature of an actual language version, like forbidding COW strings.
>

I see. Thanks for making that clear! In that case, how difficult would it
be to push for a proposal to have a feature in, say, C++20 to forbid
custom/non-trivial copy/move assignment operators for std::pair and
std::tuple?


> None of those are ABI changes. Are you sure you have an understanding of
> what an ABI change would be?
>

Maybe I'm misunderstanding it, but I thought it was a change in some core,
possibly internal, behavior of the library, in such a way that backwards
compatibility is difficult if not impossible. For example, in the
std::basic_string case, the lack of COW means people can no longer rely on
the relatively trivial copying if the string is unchanged. The opposite of
an ABI breakage would be to simply add additional functionality and leave
the original ones alone.

I guess that's the wrong way to think of it. What does it mean to be an ABI
change then?


> Also, the only classes which would lose trivial copyability under the new
> wording are those that deleted their* destructors*. People generally
> don't do that.
>

Not really. The condition that at least one copy/move
constructor/assignment must be non-deleted was only added afterwards by
defect report 1734. Originally, classes that were both non-copyable and
non-movable were, under the lib(std)?c++ implementation, considered
trivially copyable until the change in wording. And such classes, although
relatively rare, do exist. For example, I recall there was this regex
library that had a class with trivial members and had neither a copy nor
move constructor/assignment, and it has lost its trivial copyability from
the wording change.

On Tuesday, December 26, 2017 at 4:32:15 PM UTC-8, Nicol Bolas wrote:
>
> On Tuesday, December 26, 2017 at 6:47:52 PM UTC-5, mr...@google.com wrote:
>>
>> The changes to `std::basic_string` which prevent COW implementations were
>>> not considered "defects", even though I would certainly consider COW
>>> implementations "quality" in the wrong direction in most cases. They were a
>>> formal part of C++11.
>>>
>>
>> Would the enforcement of preventing copy-on-write implementations for
>> std::basic_string be an ABI-breaking change?
>>
>
> Almost certainly yes. I'm not an expert on COW string implementations, but
> I'm not sure that it's reasonable for a COW `basic_string` to have the same
> internal representation as a non-COW version. And even if they could, they
> certainly wouldn't have the same ABI as an SSO-based `basic_string`, which
> means that's an optimization you would be unable to provide.
>
> It certainly would change some assumptions about performance in certain
>> cases. Also, in the same way, couldn't we consider the shift to enforcing
>> default assignment operators for std::pair and std::tuple be a quality
>> improvement, given that it helps in obtaining the transitivity of trivial
>> copyability?
>>
>
> But it would not be a* defect* change; that's what we're talking about.
> The magnitude of such a change is such that it's not something that's
> reasonable for a mere defect report & fix. It would have to be a genuine
> feature of an actual language version, like forbidding COW strings.
>
> No, that's different. It was never the intent to make types with deleted
>>> destructors be trivially copyable. That was merely a mistake; fixing it had
>>> nothing to do with library variance.
>>>
>>
>>>
>> Also, that defect was first reported in 2013; it just took a while for
>>> them to work out a fix for it. Lastly, making such a change does not
>>> require breaking the ABI of any library implementation.
>>>
>>
>> Then what about the fact that each copy/move constructor/assignment could
>> be deleted and still maintain trivial copyability? Or the fact that at
>> least one of them must not be deleted? In the former case, due to the
>> wording of "non-trivial," MSVC implemented it as requiring all copy/move
>> constructors/assignments to be defined and defaulted, and the change in the
>> wording breaks that assumption. In the latter case, lib(std)?c++ was okay
>> with all of them being deleted, which is a far more severe breakage in that
>> class previously considered trivially copyable are no longer so after the
>> wording change.
>>
>
> None of those are ABI changes. Are you sure you have an understanding of
> what an ABI change would be?
>
> Also, the only classes which would lose trivial copyability under the new
> wording are those that deleted their* destructors*. People generally
> don't do that.
>

--
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/f3a9fa10-0ea8-4715-8cbc-328f01410f34%40isocpp.org.

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

<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;"><div dir=3D"ltr"><div>But it would not be a<i>=C2=A0defect</i>=C2=A0ch=
ange; that&#39;s what we&#39;re talking about. The magnitude of such a chan=
ge is such that it&#39;s not something that&#39;s reasonable for a mere def=
ect report &amp; fix. It would have to be a genuine feature of an actual la=
nguage version, like forbidding COW strings.<br></div></div></blockquote><d=
iv><br></div><div>I see. Thanks for making that clear! In that case, how di=
fficult would it be to push for a proposal to have a feature in, say, C++20=
 to forbid custom/non-trivial copy/move assignment operators for std::pair =
and std::tuple?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>None of those are ABI=
 changes. Are you sure you have an understanding of what an ABI change woul=
d be?<br></div></div></blockquote><div><br></div><div>Maybe I&#39;m misunde=
rstanding it, but I thought it was a change in some core, possibly internal=
, behavior of the library, in such a way that backwards compatibility is di=
fficult if not impossible. For example, in the std::basic_string case, the =
lack of COW means people can no longer rely on the relatively trivial copyi=
ng if the string is unchanged. The opposite of an ABI breakage would be to =
simply add additional functionality and leave the original ones alone.</div=
><div><br></div><div>I guess that&#39;s the wrong way to think of it. What =
does it mean to be an ABI change then?</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div>Also, the=
 only classes which would lose trivial copyability under the new wording ar=
e those that deleted their<i>=C2=A0destructors</i>. People generally don&#3=
9;t do that.<br></div></div></blockquote></div><div><br></div><div>Not real=
ly. The condition that at least one copy/move constructor/assignment must b=
e non-deleted was only added afterwards by defect report 1734. Originally, =
classes that were both non-copyable and non-movable were, under the lib(std=
)?c++ implementation, considered trivially copyable until the change in wor=
ding. And such classes, although relatively rare, do exist. For example, I =
recall there was this regex library that had a class with trivial members a=
nd had neither a copy nor move constructor/assignment, and it has lost its =
trivial copyability from the wording change.</div><br>On Tuesday, December =
26, 2017 at 4:32:15 PM UTC-8, Nicol Bolas wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr">On Tuesday, December 26, 2017 at 6:47:52=
 PM UTC-5, <a>mr...@google.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><div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr">The changes to `std::basic_string` which prevent C=
OW implementations were not considered &quot;defects&quot;, even though I w=
ould certainly consider COW implementations &quot;quality&quot; in the wron=
g direction in most cases. They were a formal part of C++11.</div></blockqu=
ote><div><br></div><div>Would the enforcement of preventing copy-on-write i=
mplementations for std::basic_string be an ABI-breaking change?</div></div>=
</div></div></blockquote><div><br></div><div>Almost certainly yes. I&#39;m =
not an expert on COW string implementations, but I&#39;m not sure that it&#=
39;s reasonable for a COW `basic_string` to have the same internal represen=
tation as a non-COW version. And even if they could, they certainly wouldn&=
#39;t have the same ABI as an SSO-based `basic_string`, which means that&#3=
9;s an optimization you would be unable to provide.</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>It cer=
tainly would change some assumptions about performance in certain cases. Al=
so, in the same way, couldn&#39;t we consider the shift to enforcing defaul=
t assignment operators for std::pair and std::tuple be a quality improvemen=
t, given that it helps in obtaining the transitivity of trivial copyability=
?</div></div></div></div></blockquote><div><br></div><div>But it would not =
be a<i> defect</i> change; that&#39;s what we&#39;re talking about. The mag=
nitude of such a change is such that it&#39;s not something that&#39;s reas=
onable for a mere defect report &amp; fix. It would have to be a genuine fe=
ature of an actual language version, like forbidding COW strings.</div><div=
><i></i><i></i><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div d=
ir=3D"ltr">No, that&#39;s different. It was never the intent to make types =
with deleted destructors be trivially copyable. That was merely a mistake; =
fixing it had nothing to do with library variance.=C2=A0</div></blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=C2=A0</=
div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><div></div><div>Also, that defect was first reported in 2013; it j=
ust took a while for them to work out a fix for it. Lastly, making such a c=
hange does not require breaking the ABI of any library implementation.</div=
></div></blockquote><div><br></div><div>Then what about the fact that each =
copy/move constructor/assignment could be deleted and still maintain trivia=
l copyability? Or the fact that at least one of them must not be deleted? I=
n the former case, due to the wording of &quot;non-trivial,&quot; MSVC impl=
emented it as requiring all copy/move constructors/assignments to be define=
d and defaulted, and the change in the wording breaks that assumption. In t=
he latter case, lib(std)?c++ was okay with all of them being deleted, which=
 is a far more severe breakage in that class previously considered triviall=
y copyable are no longer so after the wording change.</div></div></div></di=
v></blockquote><div><br></div><div>None of those are ABI changes. Are you s=
ure you have an understanding of what an ABI change would be?</div><div><br=
></div><div>Also, the only classes which would lose trivial copyability und=
er the new wording are those that deleted their<i> destructors</i>. People =
generally don&#39;t do that.<br></div></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&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/f3a9fa10-0ea8-4715-8cbc-328f01410f34%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f3a9fa10-0ea8-4715-8cbc-328f01410f34=
%40isocpp.org</a>.<br />

------=_Part_19846_379493373.1514336317799--

------=_Part_19845_339820878.1514336317799--

.

On ter=C3=A7a-feira, 26 de dezembro de 2017 22:58:37 -02 mrpi via ISO C++ S=
tandard=20
> I see. Thanks for making that clear! In that case, how difficult would it
> be to push for a proposal to have a feature in, say, C++20 to forbid
> custom/non-trivial copy/move assignment operators for std::pair and
> std::tuple?

That depends on the motivation that the paper declares. Considering you=20
already know that this is going to be an ABI-breaking change and you've=20
already heard from a Standard Library developer that doing so is possible, =
but=20
just generally cumbersome for developers that need to keep C++11=20
compatibility, the motivation had better be very good.

By the way, what is it?

> > None of those are ABI changes. Are you sure you have an understanding o=
f
> > what an ABI change would be?
>=20
> Maybe I'm misunderstanding it, but I thought it was a change in some core=
,
> possibly internal, behavior of the library, in such a way that backwards
> compatibility is difficult if not impossible. For example, in the
> std::basic_string case, the lack of COW means people can no longer rely o=
n
> the relatively trivial copying if the string is unchanged. The opposite o=
f
> an ABI breakage would be to simply add additional functionality and leave
> the original ones alone.
>
> I guess that's the wrong way to think of it. What does it mean to be an A=
BI
> change then?

Indeed, you misunderstand what it means. An ABI change is what happens when=
=20
the low-level implementation details change. Those can be changes in the or=
der=20
of elements in a structure, the order of entries in a vtable, the way=20
arguments are encoded in the stack or in registers, etc. Those may happen=
=20
without a corresponding change in the application source code (which would =
be=20
an API change).

In this case, it means that EVERY SINGLE PROGRAM that passes std::pair or=
=20
std::tuple by value or returns one of those would need to be recompiled.

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

--=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/6824004.XC1QRsfIgm%40tjmaciei-mobl1.

.