------=_Part_638_2086017879.1474571164175
Content-Type: multipart/alternative;
 boundary="----=_Part_639_1398756088.1474571164175"

------=_Part_639_1398756088.1474571164175
Content-Type: text/plain; charset=UTF-8

`optional` is not required to be trivially copyable if `T` is trivially
copyable. And yet, I cannot imagine an implementation of `optional` where
that is not at least *possible*. After all, the bit saying whether the
`optional` is empty is likely a basic type. So why should trivial
copyability not be possible?

Similarly, if all of the `Ts` for a `variant` are trivially copyable, it
should be possible to make the variant itself trivially copyable.

Is there an implementation problem I'm not aware of, or was this an
oversight? Should a national body comment be filed or a defect report be
sent?

--
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/f8ccbc4e-d67c-4af5-933a-0d2822622baa%40isocpp.org.

------=_Part_639_1398756088.1474571164175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">`optional` is not required to be trivially copyable if `T`=
 is trivially copyable. And yet, I cannot imagine an implementation of `opt=
ional` where that is not at least <i>possible</i>. After all, the bit sayin=
g whether the `optional` is empty is likely a basic type. So why should tri=
vial copyability not be possible?<br><br>Similarly, if all of the `Ts` for =
a `variant` are trivially copyable, it should be possible to make the varia=
nt itself trivially copyable.<br><br>Is there an implementation problem I&#=
39;m not aware of, or was this an oversight? Should a national body comment=
 be filed or a defect report be sent?<br></div>

<p></p>

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

------=_Part_639_1398756088.1474571164175--

------=_Part_638_2086017879.1474571164175--

.

------=_Part_1922_579463712.1474580787221
Content-Type: multipart/alternative;
 boundary="----=_Part_1923_1175359735.1474580787221"

------=_Part_1923_1175359735.1474580787221
Content-Type: text/plain; charset=UTF-8

On Thursday, September 22, 2016 at 12:06:04 PM UTC-7, Nicol Bolas wrote:
>
> `optional` is not required to be trivially copyable if `T` is trivially
> copyable. And yet, I cannot imagine an implementation of `optional` where
> that is not at least *possible*. After all, the bit saying whether the
> `optional` is empty is likely a basic type. So why should trivial
> copyability not be possible?
>
> Similarly, if all of the `Ts` for a `variant` are trivially copyable, it
> should be possible to make the variant itself trivially copyable.
>
> Is there an implementation problem I'm not aware of, or was this an
> oversight? Should a national body comment be filed or a defect report be
> sent?
>

Those requirements are implementable: the Microsoft implementations of
optional and variant maintain trivial copyability of the contained types.
It seems to be QoI to me; I see no strong motivation to *require* that
behavior.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/47c7c8cf-13f4-4026-acf4-41ca1d2a3e53%40isocpp.org.

------=_Part_1923_1175359735.1474580787221
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, September 22, 2016 at 12:06:04 PM UTC-7, 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"=
>`optional` is not required to be trivially copyable if `T` is trivially co=
pyable. And yet, I cannot imagine an implementation of `optional` where tha=
t is not at least <i>possible</i>. After all, the bit saying whether the `o=
ptional` is empty is likely a basic type. So why should trivial copyability=
 not be possible?<br><br>Similarly, if all of the `Ts` for a `variant` are =
trivially copyable, it should be possible to make the variant itself trivia=
lly copyable.<br><br>Is there an implementation problem I&#39;m not aware o=
f, or was this an oversight? Should a national body comment be filed or a d=
efect report be sent?<br></div></blockquote><div><br></div><div>Those requi=
rements are implementable: the Microsoft implementations of optional and va=
riant maintain trivial copyability of the contained types. It seems to be Q=
oI to me; I see no strong motivation to *require* that behavior.</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/47c7c8cf-13f4-4026-acf4-41ca1d2a3e53%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/47c7c8cf-13f4-4026-acf4-41ca1d2a3e53=
%40isocpp.org</a>.<br />

------=_Part_1923_1175359735.1474580787221--

------=_Part_1922_579463712.1474580787221--

.

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

On Thu, Sep 22, 2016 at 2:46 PM, Casey Carter <cartec69@gmail.com> wrote:

> On Thursday, September 22, 2016 at 12:06:04 PM UTC-7, Nicol Bolas wrote:
>>
>> `optional` is not required to be trivially copyable if `T` is trivially
>> copyable. And yet, I cannot imagine an implementation of `optional` where
>> that is not at least *possible*. After all, the bit saying whether the
>> `optional` is empty is likely a basic type. So why should trivial
>> copyability not be possible?
>>
>> Similarly, if all of the `Ts` for a `variant` are trivially copyable, it
>> should be possible to make the variant itself trivially copyable.
>>
>> Is there an implementation problem I'm not aware of, or was this an
>> oversight? Should a national body comment be filed or a defect report be
>> sent?
>>
>
> Those requirements are implementable: the Microsoft implementations of
> optional and variant maintain trivial copyability of the contained types.
> It seems to be QoI to me; I see no strong motivation to *require* that
> behavior.
>

I mostly agree. I don't think it's a defect, but I do think that requiring
triviality is the direction that we should go in a future standard. My main
reason for thinking we should require triviality post-c++17 is mostly just
because I think having a somewhat-usable constexpr variant is worthwhile.
At the moment, due to language restrictions (that I personally consider
defects) it is not possible to implement a constexpr copy or move operation
for a variant *unless* the copy/move operation is trivial. So while I think
it's useful to be able to guarantee triviality, I think the more important
thing is guaranteeing at least some variant instantiations are a reasonable
literal type, which in practice ends up requiring the operation to be
trivial anyway.

Apart from constexpr, there is at least one other reason to require
triviality eventually anyway -- while it is rare, it is sometimes a
requirement of niche datastructures to have an element type that is
trivially copyable (i.e. certain lockfree datastructures). It would be
pretty cool if a standard variant with appropriate parameters (or any
algebraic data type for that matter) were guaranteed to meet these
requirements.

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Sep 22, 2016 at 2:46 PM, Casey Carter <span dir=3D"ltr">&lt;<a href=3D"=
mailto:cartec69@gmail.com" target=3D"_blank">cartec69@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"">On Thursday, September 22, 2016 at 12:06:04 PM UTC-7, Nicol Bolas wro=
te:<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">`optional` is n=
ot required to be trivially copyable if `T` is trivially copyable. And yet,=
 I cannot imagine an implementation of `optional` where that is not at leas=
t <i>possible</i>. After all, the bit saying whether the `optional` is empt=
y is likely a basic type. So why should trivial copyability not be possible=
?<br><br>Similarly, if all of the `Ts` for a `variant` are trivially copyab=
le, it should be possible to make the variant itself trivially copyable.<br=
><br>Is there an implementation problem I&#39;m not aware of, or was this a=
n oversight? Should a national body comment be filed or a defect report be =
sent?<br></div></blockquote><div><br></div></span><div>Those requirements a=
re implementable: the Microsoft implementations of optional and variant mai=
ntain trivial copyability of the contained types. It seems to be QoI to me;=
 I see no strong motivation to *require* that behavior.</div></div></blockq=
uote><div><br></div><div>I mostly agree. I don&#39;t think it&#39;s a defec=
t, but I do think that requiring triviality is the direction that we should=
 go in a future standard. My main reason for thinking we should require tri=
viality post-c++17 is mostly just because I think having a somewhat-usable =
constexpr variant is worthwhile. At the moment, due to language restriction=
s (that I personally consider defects) it is not possible to implement a co=
nstexpr copy or move operation for a variant <i>unless</i>=C2=A0the copy/mo=
ve operation is trivial. So while I think it&#39;s useful to be able to gua=
rantee triviality, I think the more important thing is guaranteeing at leas=
t some variant instantiations are a reasonable literal type, which in pract=
ice ends up requiring the operation to be trivial anyway.</div><div><br></d=
iv><div>Apart from constexpr, there is at least one other reason to require=
 triviality eventually anyway -- while it is rare, it is sometimes a requir=
ement of niche datastructures to have an element type that is trivially cop=
yable (i.e. certain lockfree datastructures). It would be pretty cool if a =
standard variant with appropriate parameters (or any algebraic data type fo=
r that matter) were guaranteed to meet these requirements.</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/CANh8DEmfYFNbUgbzrn9aV0ZKwAPQbqw78tfS=
QfyOs118PvyqcQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEmfYFNbUgbz=
rn9aV0ZKwAPQbqw78tfSQfyOs118PvyqcQ%40mail.gmail.com</a>.<br />

--94eb2c18ffbea85907053d200cd1--

.

On 23 September 2016 at 00:46, Casey Carter <cartec69@gmail.com> wrote:
> Those requirements are implementable: the Microsoft implementations of
> optional and variant maintain trivial copyability of the contained types. It
> seems to be QoI to me; I see no strong motivation to *require* that
> behavior.


Portability would seem like a fairly good motivation for that to me.

--
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/CAFk2RUZ5a%2Bfwj%2BfXhqFfVYmtxitLu7xFrhJ%2BkHY-QUOWb3hEmg%40mail.gmail.com.

.

------=_Part_10310_825460880.1514031421274
Content-Type: multipart/alternative;
 boundary="----=_Part_10311_920418220.1514031421274"

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

Is there any progress being made on this? As I see now the Microsoft and=20
libc++ implementation maintain trivial copyability, but libstdc++=20
doesn't: https://godbolt.org/g/tL29Hd

=D1=87=D0=B5=D1=82=D0=B2=D0=B5=D1=80=D0=B3, 22 =D1=81=D0=B5=D0=BD=D1=82=D1=
=8F=D0=B1=D1=80=D1=8F 2016 =D0=B3., 22:06:04 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=
=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> `optional` is not required to be trivially copyable if `T` is trivially=
=20
> copyable. And yet, I cannot imagine an implementation of `optional` where=
=20
> that is not at least *possible*. After all, the bit saying whether the=20
> `optional` is empty is likely a basic type. So why should trivial=20
> copyability not be possible?
>
> Similarly, if all of the `Ts` for a `variant` are trivially copyable, it=
=20
> should be possible to make the variant itself trivially copyable.
>
> Is there an implementation problem I'm not aware of, or was this an=20
> oversight? Should a national body comment be filed or a defect report be=
=20
> sent?
>

--=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/390b06f2-0c86-465e-9a11-d0ebb3501970%40isocpp.or=
g.

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

<div dir=3D"ltr">Is there any progress being made on this? As I see now the=
 Microsoft and libc++ implementation maintain trivial copyability, but libs=
tdc++ doesn&#39;t:=C2=A0https://godbolt.org/g/tL29Hd<br><br>=D1=87=D0=B5=D1=
=82=D0=B2=D0=B5=D1=80=D0=B3, 22 =D1=81=D0=B5=D0=BD=D1=82=D1=8F=D0=B1=D1=80=
=D1=8F 2016 =D0=B3., 22:06:04 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=D0=BE=D0=
=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Nicol Bolas =D0=BD=D0=B0=D0=BF=D0=B8=D1=
=81=D0=B0=D0=BB:<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">`optional` is not required to be trivially copyable if `T` is trivially =
copyable. And yet, I cannot imagine an implementation of `optional` where t=
hat is not at least <i>possible</i>. After all, the bit saying whether the =
`optional` is empty is likely a basic type. So why should trivial copyabili=
ty not be possible?<br><br>Similarly, if all of the `Ts` for a `variant` ar=
e trivially copyable, it should be possible to make the variant itself triv=
ially copyable.<br><br>Is there an implementation problem I&#39;m not aware=
 of, or was this an oversight? Should a national body comment be filed or a=
 defect report be sent?<br></div></blockquote></div>

<p></p>

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

------=_Part_10311_920418220.1514031421274--

------=_Part_10310_825460880.1514031421274--

.

On 23 December 2017 at 14:17, Andrey Davydov <andrey.a.davydov@gmail.com> wrote:
> Is there any progress being made on this? As I see now the Microsoft and
> libc++ implementation maintain trivial copyability, but libstdc++ doesn't:
> https://godbolt.org/g/tL29Hd

The proposal for that hasn't apparently been adopted yet, so this
hasn't popped up as a high-priority
item on the libstdc++ todo list. I suppose I should implement it
anyway, but I can't make any promises
that it'll make it into gcc 8.

--
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/CAFk2RUY8UDDb2NXs0FdPCbCUYvzLmjYfu_GkU3FgzPiiOXX%2BTQ%40mail.gmail.com.

.

------=_Part_14011_1141074066.1514166014789
Content-Type: multipart/alternative;
 boundary="----=_Part_14012_539206530.1514166014790"

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

On Saturday, December 23, 2017 at 4:47:05 AM UTC-8, Ville Voutilainen wrote=
:
>
> On 23 December 2017 at 14:17, Andrey Davydov <andrey.a...@gmail.com=20
> <javascript:>> wrote:=20
> > Is there any progress being made on this? As I see now the Microsoft an=
d=20
> > libc++ implementation maintain trivial copyability, but libstdc++=20
> doesn't:=20
> > https://godbolt.org/g/tL29Hd=20
>
> The proposal for that hasn't apparently been adopted yet, so this=20
> hasn't popped up as a high-priority=20
> item on the libstdc++ todo list. I suppose I should implement it=20
> anyway, but I can't make any promises=20
> that it'll make it into gcc 8.
>

Coincidentally, "trivial copyability of std::optional" just popped up over=
=20
on the SG14 list as well:
https://groups.google.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s/iNVCL3n=
aDAAJ

The fundamental problem (IMO) is that if you make optional<T> trivially=20
copyable, then you have

    optional<int> a =3D 42;  // correctly constructs an `int` and begins it=
s=20
lifetime
    optional<int> b =3D a;  // trivially copies some bits into the memory=
=20
address of `b`

In the `b` case, there is no `int` object actually constructed (assuming=20
the common implementation of `optional<T>` as containing a union of a dummy=
=20
char and a `T` object, where the `T` object is not constructed by default).=
=20
So the first access to `b.value()` invokes undefined behavior, as far as=20
I'm aware.

I believe that this problem (A) does not cause incorrect codegen in=20
practice because compilers don't optimize on lifetime information yet; and=
=20
(B) is actively being tackled by papers such as Ville & Richard's P0593r1=
=20
so that such optimizations might be implementable in the future.

If P0593r1 is adopted in its current form, then optional<T> will be able to=
=20
be trivially_copyable whenever T is trivially_copyable; however, there will=
=20
be cases where the trivialness of the copy constructor cannot be propagated=
=20
because of a non-trivial destructor, or vice versa.

=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/0f45770f-dc62-4459-8e1c-6aece46d05e6%40isocpp.or=
g.

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

<div dir=3D"ltr">On Saturday, December 23, 2017 at 4:47:05 AM UTC-8, Ville =
Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 23 Decemb=
er 2017 at 14:17, Andrey Davydov &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"zIXt-92lBwAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">andrey.a...@gmail.com</a>&gt; wrote:
<br>&gt; Is there any progress being made on this? As I see now the Microso=
ft and
<br>&gt; libc++ implementation maintain trivial copyability, but libstdc++ =
doesn&#39;t:
<br>&gt; <a href=3D"https://godbolt.org/g/tL29Hd" target=3D"_blank" rel=3D"=
nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3dh=
ttps%3A%2F%2Fgodbolt.org%2Fg%2FtL29Hd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQ=
jCNGfgkB2cXDRCoD6cMOuz6RimBAS-g&#39;;return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FtL29Hd\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGfgkB2cXDRCoD6cMOuz6RimBAS-g&#39;;r=
eturn true;">https://godbolt.org/g/tL29Hd</a>
<br>
<br>The proposal for that hasn&#39;t apparently been adopted yet, so this
<br>hasn&#39;t popped up as a high-priority
<br>item on the libstdc++ todo list. I suppose I should implement it
<br>anyway, but I can&#39;t make any promises
<br>that it&#39;ll make it into gcc 8.<br></blockquote><div><br></div><div>=
Coincidentally, &quot;trivial copyability of std::optional&quot; just poppe=
d up over on the SG14 list as well:</div><div><a href=3D"https://groups.goo=
gle.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s/iNVCL3naDAAJ">https://gro=
ups.google.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s/iNVCL3naDAAJ</a><b=
r></div><div><br></div><div>The fundamental problem (IMO) is that if you ma=
ke optional&lt;T&gt; trivially copyable, then you have</div><div><br></div>=
<div>=C2=A0 =C2=A0 optional&lt;int&gt; a =3D 42; =C2=A0// correctly constru=
cts an `int` and begins its lifetime</div><div>=C2=A0 =C2=A0 optional&lt;in=
t&gt; b =3D a; =C2=A0// trivially copies some bits into the memory address =
of `b`</div><div><br></div><div>In the `b` case, there is no `int` object a=
ctually constructed (assuming the common implementation of `optional&lt;T&g=
t;` as containing a union of a dummy char and a `T` object, where the `T` o=
bject is not constructed by default). So the first access to `b.value()` in=
vokes undefined behavior, as far as I&#39;m aware.</div><div><br></div><div=
>I believe that this problem (A) does not cause incorrect codegen in practi=
ce because compilers don&#39;t optimize on lifetime information yet; and (B=
) is actively being tackled by papers such as Ville &amp; Richard&#39;s P05=
93r1 so that such optimizations might be implementable in the future.</div>=
<div><br></div><div>If P0593r1 is adopted in its current form, then optiona=
l&lt;T&gt; will be able to be trivially_copyable whenever T is trivially_co=
pyable; however, there will be cases where the trivialness of the copy cons=
tructor cannot be propagated because of a non-trivial destructor, or vice v=
ersa.</div><div><br></div><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/0f45770f-dc62-4459-8e1c-6aece46d05e6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0f45770f-dc62-4459-8e1c-6aece46d05e6=
%40isocpp.org</a>.<br />

------=_Part_14012_539206530.1514166014790--

------=_Part_14011_1141074066.1514166014789--

.

------=_Part_14501_1636509730.1514175339816
Content-Type: multipart/alternative;
 boundary="----=_Part_14502_392247051.1514175339817"

------=_Part_14502_392247051.1514175339817
Content-Type: text/plain; charset="UTF-8"



On Sunday, December 24, 2017 at 8:40:14 PM UTC-5, Arthur O'Dwyer wrote:
>
> On Saturday, December 23, 2017 at 4:47:05 AM UTC-8, Ville Voutilainen
> wrote:
>>
>> On 23 December 2017 at 14:17, Andrey Davydov <andrey.a...@gmail.com>
>> wrote:
>> > Is there any progress being made on this? As I see now the Microsoft
>> and
>> > libc++ implementation maintain trivial copyability, but libstdc++
>> doesn't:
>> > https://godbolt.org/g/tL29Hd
>>
>> The proposal for that hasn't apparently been adopted yet, so this
>> hasn't popped up as a high-priority
>> item on the libstdc++ todo list. I suppose I should implement it
>> anyway, but I can't make any promises
>> that it'll make it into gcc 8.
>>
>
> Coincidentally, "trivial copyability of std::optional" just popped up over
> on the SG14 list as well:
>
> https://groups.google.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s/iNVCL3naDAAJ
>
> The fundamental problem (IMO) is that if you make optional<T> trivially
> copyable, then you have
>
>     optional<int> a = 42;  // correctly constructs an `int` and begins its
> lifetime
>     optional<int> b = a;  // trivially copies some bits into the memory
> address of `b`
>
> In the `b` case, there is no `int` object actually constructed (assuming
> the common implementation of `optional<T>` as containing a union of a dummy
> char and a `T` object, where the `T` object is not constructed by default).
> So the first access to `b.value()` invokes undefined behavior, as far as
> I'm aware.
>

That would basically mean that any trivially copyable `union` type cannot
be copied at all. I don't buy that the standard says that. Indeed, it very
much does not [basic.types]/3:

> For any trivially copyable type T, if two pointers to T point to distinct
T objects obj1 and obj2, where neither obj1 nor obj2 is a base-class
subobject, if the underlying bytes (4.4) making up obj1 are copied into
obj2 , 44 obj2 shall subsequently hold the same value as obj1.

And that's just for doing a memcpy-based copy assignment.

For a `union`, to "hold the same value" as another instance of that union
also means to have active the same member subobject as the other `union`.
Do you have some specific statement in the standard that says 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/36d5cdb5-0213-4efd-9d36-8179177f604b%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Sunday, December 24, 2017 at 8:40:14 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 Saturday, December 23, 2017 at 4:47:05 AM UTC-8, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 December 2017 at=
 14:17, Andrey Davydov &lt;<a rel=3D"nofollow">andrey.a...@gmail.com</a>&gt=
; wrote:
<br>&gt; Is there any progress being made on this? As I see now the Microso=
ft and
<br>&gt; libc++ implementation maintain trivial copyability, but libstdc++ =
doesn&#39;t:
<br>&gt; <a onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\x3=
dhttps%3A%2F%2Fgodbolt.org%2Fg%2FtL29Hd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNGfgkB2cXDRCoD6cMOuz6RimBAS-g&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FtL2=
9Hd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGfgkB2cXDRCoD6cMOuz6RimBAS-g&#3=
9;;return true;" href=3D"https://godbolt.org/g/tL29Hd" target=3D"_blank" re=
l=3D"nofollow">https://godbolt.org/g/tL29Hd</a>
<br>
<br>The proposal for that hasn&#39;t apparently been adopted yet, so this
<br>hasn&#39;t popped up as a high-priority
<br>item on the libstdc++ todo list. I suppose I should implement it
<br>anyway, but I can&#39;t make any promises
<br>that it&#39;ll make it into gcc 8.<br></blockquote><div><br></div><div>=
Coincidentally, &quot;trivial copyability of std::optional&quot; just poppe=
d up over on the SG14 list as well:</div><div><a onmousedown=3D"this.href=
=3D&#39;https://groups.google.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s=
/iNVCL3naDAAJ&#39;;return true;" onclick=3D"this.href=3D&#39;https://groups=
..google.com/a/isocpp.org/forum/#!msg/sg14/ZqrAbZ2Vq9s/iNVCL3naDAAJ&#39;;ret=
urn true;" href=3D"https://groups.google.com/a/isocpp.org/forum/#!msg/sg14/=
ZqrAbZ2Vq9s/iNVCL3naDAAJ" target=3D"_blank" rel=3D"nofollow">https://groups=
..google.com/a/<wbr>isocpp.org/forum/#!msg/sg14/<wbr>ZqrAbZ2Vq9s/iNVCL3naDAA=
J</a><br></div><div><br></div><div>The fundamental problem (IMO) is that if=
 you make optional&lt;T&gt; trivially copyable, then you have</div><div><br=
></div><div>=C2=A0 =C2=A0 optional&lt;int&gt; a =3D 42; =C2=A0// correctly =
constructs an `int` and begins its lifetime</div><div>=C2=A0 =C2=A0 optiona=
l&lt;int&gt; b =3D a; =C2=A0// trivially copies some bits into the memory a=
ddress of `b`</div><div><br></div><div>In the `b` case, there is no `int` o=
bject actually constructed (assuming the common implementation of `optional=
&lt;T&gt;` as containing a union of a dummy char and a `T` object, where th=
e `T` object is not constructed by default). So the first access to `b.valu=
e()` invokes undefined behavior, as far as I&#39;m aware.</div></div></bloc=
kquote><div><br></div><div>That would basically mean that any trivially cop=
yable `union` type cannot be copied at all. I don&#39;t buy that the standa=
rd says that. Indeed, it very much does not [basic.types]/3:</div><div><br>=
</div><div>&gt;=C2=A0For any trivially copyable type T, if two pointers to =
T point to distinct T objects obj1 and obj2, where neither obj1 nor obj2 is=
 a base-class subobject, if the underlying bytes (4.4) making up obj1 are c=
opied into obj2 , 44 obj2 shall subsequently hold the same value as obj1.</=
div><div><br></div><div>And that&#39;s just for doing a memcpy-based copy a=
ssignment.</div><div><br></div><div>For a `union`, to &quot;hold the same v=
alue&quot; as another instance of that union also means to have active the =
same member subobject as the other `union`. Do you have some specific state=
ment in the standard that says otherwise?</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/36d5cdb5-0213-4efd-9d36-8179177f604b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36d5cdb5-0213-4efd-9d36-8179177f604b=
%40isocpp.org</a>.<br />

------=_Part_14502_392247051.1514175339817--

------=_Part_14501_1636509730.1514175339816--

.

On 23 December 2017 at 14:47, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 23 December 2017 at 14:17, Andrey Davydov <andrey.a.davydov@gmail.com> wrote:
>> Is there any progress being made on this? As I see now the Microsoft and
>> libc++ implementation maintain trivial copyability, but libstdc++ doesn't:
>> https://godbolt.org/g/tL29Hd
>
> The proposal for that hasn't apparently been adopted yet, so this
> hasn't popped up as a high-priority
> item on the libstdc++ todo list. I suppose I should implement it
> anyway, but I can't make any promises
> that it'll make it into gcc 8.

...but there's a good chance that it might:
https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01524.html

--
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/CAFk2RUayMoZDBn6hmHpocP2NmR5%2BU4vvdKRaLibsdB2v_Tt5yA%40mail.gmail.com.

.

------=_Part_18355_896347253.1514286042294
Content-Type: multipart/alternative;
 boundary="----=_Part_18356_333447722.1514286042294"

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

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 26 =D0=B4=D0=B5=D0=BA=D0=B0=D0=
=B1=D1=80=D1=8F 2017 =D0=B3., 1:01:01 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ville Voutilainen=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On 23 December 2017 at 14:47, Ville Voutilainen=20
> <ville.vo...@gmail.com <javascript:>> wrote:=20
> > On 23 December 2017 at 14:17, Andrey Davydov <andrey.a...@gmail.com=20
> <javascript:>> wrote:=20
> >> Is there any progress being made on this? As I see now the Microsoft=
=20
> and=20
> >> libc++ implementation maintain trivial copyability, but libstdc++=20
> doesn't:=20
> >> https://godbolt.org/g/tL29Hd=20
> >=20
> > The proposal for that hasn't apparently been adopted yet, so this=20
> > hasn't popped up as a high-priority=20
> > item on the libstdc++ todo list. I suppose I should implement it=20
> > anyway, but I can't make any promises=20
> > that it'll make it into gcc 8.=20
>
> ..but there's a good chance that it might:=20
> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01524.html

Many thanks to The Elf for the quick patch!

The proposal for that hasn't apparently been adopted yet...
>
I haven't managed to find any proposal or library issue about this. Could=
=20
you point out to it or should I create proposal/library issue?
=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/f7a5fad0-0a1d-4173-aa4a-2db8b109030d%40isocpp.or=
g.

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

<div dir=3D"ltr">=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 26 =D0=B4=D0=
=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2017 =D0=B3., 1:01:01 UTC+3 =D0=BF=D0=BE=
=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ville Voutilai=
nen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">On 23 December 2017 at 14:47, Ville Voutilainen
<br>&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
BoSMdkFhCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt; On 23 December 2017 at 14:17, Andrey Davydov &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"BoSMdkFhCAAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">andrey.a...@gmail.com<=
/a>&gt; wrote:
<br>&gt;&gt; Is there any progress being made on this? As I see now the Mic=
rosoft and
<br>&gt;&gt; libc++ implementation maintain trivial copyability, but libstd=
c++ doesn&#39;t:
<br>&gt;&gt; <a href=3D"https://godbolt.org/g/tL29Hd" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FtL29Hd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNGfgkB2cXDRCoD6cMOuz6RimBAS-g&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FtL2=
9Hd\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGfgkB2cXDRCoD6cMOuz6RimBAS-g&#3=
9;;return true;">https://godbolt.org/g/tL29Hd</a>
<br>&gt;
<br>&gt; The proposal for that hasn&#39;t apparently been adopted yet, so t=
his
<br>&gt; hasn&#39;t popped up as a high-priority
<br>&gt; item on the libstdc++ todo list. I suppose I should implement it
<br>&gt; anyway, but I can&#39;t make any promises
<br>&gt; that it&#39;ll make it into gcc 8.
<br>
<br>..but there&#39;s a good chance that it might:
<br><a href=3D"https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01524.html" ta=
rget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fml%2Fgcc-patches%2F2017-1=
2%2Fmsg01524.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHltpFzHaSl_NYzVom=
E_-igConGkQ&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.goog=
le.com/url?q\x3dhttps%3A%2F%2Fgcc.gnu.org%2Fml%2Fgcc-patches%2F2017-12%2Fms=
g01524.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHltpFzHaSl_NYzVomE_-igC=
onGkQ&#39;;return true;">https://gcc.gnu.org/ml/gcc-<wbr>patches/2017-12/ms=
g01524.html</a></blockquote><div>Many thanks to The Elf for the quick patch=
!</div><div><br></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;">The proposal for that hasn&#39;t apparently been adopted yet...<br></b=
lockquote><div>I haven&#39;t managed to find any proposal or library issue =
about this. Could you point out to it or should I create proposal/library i=
ssue?</div><div>=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/f7a5fad0-0a1d-4173-aa4a-2db8b109030d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7a5fad0-0a1d-4173-aa4a-2db8b109030d=
%40isocpp.org</a>.<br />

------=_Part_18356_333447722.1514286042294--

------=_Part_18355_896347253.1514286042294--

.

On 26 December 2017 at 13:00, Andrey Davydov <andrey.a.davydov@gmail.com> wrote:
>> The proposal for that hasn't apparently been adopted yet...
>
> I haven't managed to find any proposal or library issue about this. Could
> you point out to it or should I create proposal/library issue?

Here: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0602r1.html

--
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/CAFk2RUbdxC8stSRG80Ktk1rmxc3B53vbCVZ9%3DcR4zFcDQZMsjQ%40mail.gmail.com.

.

------=_Part_18434_1410154860.1514291560483
Content-Type: multipart/alternative;
 boundary="----=_Part_18435_198912260.1514291560483"

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

=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 26 =D0=B4=D0=B5=D0=BA=D0=B0=D0=
=B1=D1=80=D1=8F 2017 =D0=B3., 15:28:23 UTC+3 =D0=BF=D0=BE=D0=BB=D1=8C=D0=B7=
=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ville Voutilainen=20
=D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:
>
> On 26 December 2017 at 13:00, Andrey Davydov <andrey.a...@gmail.com=20
> <javascript:>> wrote:=20
> >> The proposal for that hasn't apparently been adopted yet...=20
> >=20
> > I haven't managed to find any proposal or library issue about this.=20
> Could=20
> > you point out to it or should I create proposal/library issue?=20
>
> Here: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0602r1.html=20
>
Thanks again!

--=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/2bd390e5-5954-43eb-8ee8-9eb06d58e629%40isocpp.or=
g.

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

<div dir=3D"ltr">=D0=B2=D1=82=D0=BE=D1=80=D0=BD=D0=B8=D0=BA, 26 =D0=B4=D0=
=B5=D0=BA=D0=B0=D0=B1=D1=80=D1=8F 2017 =D0=B3., 15:28:23 UTC+3 =D0=BF=D0=BE=
=D0=BB=D1=8C=D0=B7=D0=BE=D0=B2=D0=B0=D1=82=D0=B5=D0=BB=D1=8C Ville Voutilai=
nen =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">On 26 December 2017 at 13:00, Andrey Davydov &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"W8NBcpaQCAAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">andrey.a...@=
gmail.com</a>&gt; wrote:
<br>&gt;&gt; The proposal for that hasn&#39;t apparently been adopted yet..=
..
<br>&gt;
<br>&gt; I haven&#39;t managed to find any proposal or library issue about =
this. Could
<br>&gt; you point out to it or should I create proposal/library issue?
<br>
<br>Here: <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0=
602r1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%=
2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0602r1.html\x26sa\x3dD\x26sntz\x3d1\x26usg=
\x3dAFQjCNGRbeSw8CvTa5NFFhgm4ok_ZChUig&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%=
2FSC22%2FWG21%2Fdocs%2Fpapers%2F2017%2Fp0602r1.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNGRbeSw8CvTa5NFFhgm4ok_ZChUig&#39;;return true;">http://ope=
n-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2017/p0602r1.<wbr>html</a>
<br></blockquote><div>Thanks again!</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/2bd390e5-5954-43eb-8ee8-9eb06d58e629%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2bd390e5-5954-43eb-8ee8-9eb06d58e629=
%40isocpp.org</a>.<br />

------=_Part_18435_198912260.1514291560483--

------=_Part_18434_1410154860.1514291560483--

.