Topic: default assignment should be established by construction


Author: "'wkaras@yahoo.com' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 23 Mar 2018 12:02:25 -0700 (PDT)
Raw View
------=_Part_3885_185773214.1521831745993
Content-Type: multipart/alternative;
 boundary="----=_Part_3886_351473883.1521831745993"

------=_Part_3886_351473883.1521831745993
Content-Type: text/plain; charset="UTF-8"

For a class C, if the copy constructor is not deleted or suppressed, the
default copy assignment operator should be:

C & operator = (const C &that)
{
  if (&that != this)
  {
    this->~C();
    new (this) C(that);
  }
  return *this;
}

(with const omitted from the parameter if it is omitted in the copy
constructor).

Likewise, if the move constructor is not deleted or surpressed, the default
move assignment operator should be:

C & operator = (C &&that)
{
  if (&that != this)
  {
    this->~C();
    new (this) C(std::move(that));
  }
  return *this;
}

Hypothetically this could break existing code, but I can't think of a
practical example of useful code it would 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/58813920-b8f6-4e2f-83ed-c4c299792b62%40isocpp.org.

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

<div dir=3D"ltr">For a class C, if the copy constructor is not deleted or s=
uppressed, the default copy assignment operator should be:<div><br></div><d=
iv>C &amp; operator =3D (const C &amp;that)</div><div>{</div><div>=C2=A0 if=
 (&amp;that !=3D this)</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 this-&gt;=
~C();</div><div>=C2=A0 =C2=A0 new (this) C(that);</div><div>=C2=A0 }</div><=
div>=C2=A0 return *this;</div><div>}</div><div><br></div><div>(with const o=
mitted from the parameter if it is omitted in the copy constructor).</div><=
div><br></div><div>Likewise, if the move constructor is not deleted or surp=
ressed, the default move assignment operator should be:</div><div><br></div=
><div><div>C &amp; operator =3D (C &amp;&amp;that)</div><div>{</div><div>=
=C2=A0 if (&amp;that !=3D this)</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 =
this-&gt;~C();</div><div>=C2=A0 =C2=A0 new (this) C(std::move(that));</div>=
<div>=C2=A0 }</div><div>=C2=A0 return *this;</div><div>}</div></div><div><b=
r></div><div>Hypothetically this could break existing code, but I can&#39;t=
 think of a practical example of useful code it would break.</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/58813920-b8f6-4e2f-83ed-c4c299792b62%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58813920-b8f6-4e2f-83ed-c4c299792b62=
%40isocpp.org</a>.<br />

------=_Part_3886_351473883.1521831745993--

------=_Part_3885_185773214.1521831745993--

.


Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 23 Mar 2018 14:03:38 -0500
Raw View
--001a114daec260c6b50568191763
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 23, 2018 at 2:02 PM, 'wkaras@yahoo.com' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> For a class C, if the copy constructor is not deleted or suppressed, the
> default copy assignment operator should be:
>
> C & operator = (const C &that)
> {
>   if (&that != this)
>   {
>     this->~C();
>     new (this) C(that);
>   }
>   return *this;
> }
>
> (with const omitted from the parameter if it is omitted in the copy
> constructor).
>
> Likewise, if the move constructor is not deleted or surpressed, the
> default move assignment operator should be:
>
> C & operator = (C &&that)
> {
>   if (&that != this)
>   {
>     this->~C();
>     new (this) C(std::move(that));
>   }
>   return *this;
> }
>
> Hypothetically this could break existing code, but I can't think of a
> practical example of useful code it would break.
>

Only if you live in an exception-free world...
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BNXH4jPHwLKqYeOJ%3DCCWsh2dJetCYOSNt8vfmMduZBPqQ%40mail.gmail.com.

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

<div dir=3D"ltr">On Fri, Mar 23, 2018 at 2:02 PM, &#39;<a href=3D"mailto:wk=
aras@yahoo.com">wkaras@yahoo.com</a>&#39; via ISO C++ Standard - Future Pro=
posals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" ta=
rget=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">For a class C, if the copy constructor is not deleted or =
suppressed, the default copy assignment operator should be:<div><br></div><=
div>C &amp; operator =3D (const C &amp;that)</div><div>{</div><div>=C2=A0 i=
f (&amp;that !=3D this)</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 this-&gt=
;~C();</div><div>=C2=A0 =C2=A0 new (this) C(that);</div><div>=C2=A0 }</div>=
<div>=C2=A0 return *this;</div><div>}</div><div><br></div><div>(with const =
omitted from the parameter if it is omitted in the copy constructor).</div>=
<div><br></div><div>Likewise, if the move constructor is not deleted or sur=
pressed, the default move assignment operator should be:</div><div><br></di=
v><div><div>C &amp; operator =3D (C &amp;&amp;that)</div><div>{</div><div>=
=C2=A0 if (&amp;that !=3D this)</div><div>=C2=A0 {</div><div>=C2=A0 =C2=A0 =
this-&gt;~C();</div><div>=C2=A0 =C2=A0 new (this) C(std::move(that));</div>=
<div>=C2=A0 }</div><div>=C2=A0 return *this;</div><div>}</div></div><div><b=
r></div><div>Hypothetically this could break existing code, but I can&#39;t=
 think of a practical example of useful code it would break.</div></div></b=
lockquote><div><br></div><div>Only if you live in an exception-free world..=
..=C2=A0</div></div>-- <br><div class=3D"gmail_signature" data-smartmail=3D"=
gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &q=
uot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404<=
/div></div></div></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/CAGg_6%2BNXH4jPHwLKqYeOJ%3DCCWsh2dJet=
CYOSNt8vfmMduZBPqQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNXH4=
jPHwLKqYeOJ%3DCCWsh2dJetCYOSNt8vfmMduZBPqQ%40mail.gmail.com</a>.<br />

--001a114daec260c6b50568191763--

.


Author: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 23 Mar 2018 19:17:01 +0000
Raw View
--94eb2c05b49e76730e05681945b6
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 23, 2018 at 3:04 PM Nevin Liber <nevin@eviloverlord.com> wrote:

> On Fri, Mar 23, 2018 at 2:02 PM, 'wkaras@yahoo.com' via ISO C++ Standard
> - Future Proposals <std-proposals@isocpp.org> wrote:
>
>> For a class C, if the copy constructor is not deleted or suppressed, the
>> default copy assignment operator should be:
>>
>> C & operator = (const C &that)
>> {
>>   if (&that != this)
>>   {
>>     this->~C();
>>     new (this) C(that);
>>   }
>>   return *this;
>> }
>>
>> (with const omitted from the parameter if it is omitted in the copy
>> constructor).
>>
>> Likewise, if the move constructor is not deleted or surpressed, the
>> default move assignment operator should be:
>>
>> C & operator = (C &&that)
>> {
>>   if (&that != this)
>>   {
>>     this->~C();
>>     new (this) C(std::move(that));
>>   }
>>   return *this;
>> }
>>
>> Hypothetically this could break existing code, but I can't think of a
>> practical example of useful code it would break.
>>
>
> Only if you live in an exception-free world...
>

Also, what happens if C is the base type of the object (this is troublesome
regardless of the destructor being virtual or not)? Bonus points -- what if
it has const or reference datamembers ;)

I do agree, though, that in some idealized world this could be a sensible
default.

-- Matt Calabrese

--
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/CANh8DEnu0VkAPajWWe7q%2BW4%3D_Go5xKASj-%2B%3D5MvZCk6dRkmhYw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Ma=
r 23, 2018 at 3:04 PM Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.=
com">nevin@eviloverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">On Fri, Mar 23, 2018 at 2:02 PM, &#39;<a href=3D"m=
ailto:wkaras@yahoo.com" target=3D"_blank">wkaras@yahoo.com</a>&#39; via ISO=
 C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mailto:st=
d-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a>&gt;<=
/span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">For a class C, if the copy cons=
tructor is not deleted or suppressed, the default copy assignment operator =
should be:<div><br></div><div>C &amp; operator =3D (const C &amp;that)</div=
><div>{</div><div>=C2=A0 if (&amp;that !=3D this)</div><div>=C2=A0 {</div><=
div>=C2=A0 =C2=A0 this-&gt;~C();</div><div>=C2=A0 =C2=A0 new (this) C(that)=
;</div><div>=C2=A0 }</div><div>=C2=A0 return *this;</div><div>}</div><div><=
br></div><div>(with const omitted from the parameter if it is omitted in th=
e copy constructor).</div><div><br></div><div>Likewise, if the move constru=
ctor is not deleted or surpressed, the default move assignment operator sho=
uld be:</div><div><br></div><div><div>C &amp; operator =3D (C &amp;&amp;tha=
t)</div><div>{</div><div>=C2=A0 if (&amp;that !=3D this)</div><div>=C2=A0 {=
</div><div>=C2=A0 =C2=A0 this-&gt;~C();</div><div>=C2=A0 =C2=A0 new (this) =
C(std::move(that));</div><div>=C2=A0 }</div><div>=C2=A0 return *this;</div>=
<div>}</div></div><div><br></div><div>Hypothetically this could break exist=
ing code, but I can&#39;t think of a practical example of useful code it wo=
uld break.</div></div></blockquote><div><br></div><div>Only if you live in =
an exception-free world...=C2=A0</div></div></div></div></blockquote><div><=
br></div><div>Also, what happens if C is the base type of the object (this =
is troublesome regardless of the destructor being virtual or not)? Bonus po=
ints -- what if it has const or reference datamembers ;)<br></div><div><br>=
</div><div>I do agree, though, that in some idealized world this could be a=
 sensible default.</div><div><br></div><div>-- Matt Calabrese</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/CANh8DEnu0VkAPajWWe7q%2BW4%3D_Go5xKAS=
j-%2B%3D5MvZCk6dRkmhYw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnu=
0VkAPajWWe7q%2BW4%3D_Go5xKASj-%2B%3D5MvZCk6dRkmhYw%40mail.gmail.com</a>.<br=
 />

--94eb2c05b49e76730e05681945b6--

.


Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 23 Mar 2018 12:33:39 -0700 (PDT)
Raw View
------=_Part_4005_1235032507.1521833619959
Content-Type: multipart/alternative;
 boundary="----=_Part_4006_1441833072.1521833619960"

------=_Part_4006_1441833072.1521833619960
Content-Type: text/plain; charset="UTF-8"

I don't think there's a clean escape from suckland if you're directly
calling the assignment operator of a base class.  I think the best option
would be to call the un-overridden destructor.

Can you elaborate on the problem with const and reference members?

On Friday, March 23, 2018 at 2:17:15 PM UTC-5, Matt Calabrese wrote:
>
>
> On Fri, Mar 23, 2018 at 3:04 PM Nevin Liber <ne...@eviloverlord.com
> <javascript:>> wrote:
>
>> On Fri, Mar 23, 2018 at 2:02 PM, 'wka...@yahoo.com <javascript:>' via
>> ISO C++ Standard - Future Proposals <std-pr...@isocpp.org <javascript:>>
>> wrote:
>>
>>> For a class C, if the copy constructor is not deleted or suppressed, the
>>> default copy assignment operator should be:
>>>
>>> C & operator = (const C &that)
>>> {
>>>   if (&that != this)
>>>   {
>>>     this->~C();
>>>     new (this) C(that);
>>>   }
>>>   return *this;
>>> }
>>>
>>> (with const omitted from the parameter if it is omitted in the copy
>>> constructor).
>>>
>>> Likewise, if the move constructor is not deleted or surpressed, the
>>> default move assignment operator should be:
>>>
>>> C & operator = (C &&that)
>>> {
>>>   if (&that != this)
>>>   {
>>>     this->~C();
>>>     new (this) C(std::move(that));
>>>   }
>>>   return *this;
>>> }
>>>
>>> Hypothetically this could break existing code, but I can't think of a
>>> practical example of useful code it would break.
>>>
>>
>> Only if you live in an exception-free world...
>>
>
> Also, what happens if C is the base type of the object (this is
> troublesome regardless of the destructor being virtual or not)? Bonus
> points -- what if it has const or reference datamembers ;)
>
> I do agree, though, that in some idealized world this could be a sensible
> default.
>
> -- Matt Calabrese
>

--
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/d25df281-7c9a-4a58-ace4-9d0914836959%40isocpp.org.

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

<div dir=3D"ltr">I don&#39;t think there&#39;s a clean escape from suckland=
 if you&#39;re directly calling the assignment operator of a base class.=C2=
=A0 I think the best option would be to call the un-overridden destructor.<=
br><br>Can you elaborate on the problem with const and reference members?<b=
r><br>On Friday, March 23, 2018 at 2:17:15 PM UTC-5, Matt Calabrese wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Fri, Mar 23, 2018 at 3:04 PM Nevin Lib=
er &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"A=
CL6dYA2AgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">ne...@eviloverlord.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">On Fri, Mar 23, 2018 at 2:02 PM, &#39;<a href=3D"java=
script:" target=3D"_blank" gdf-obfuscated-mailto=3D"ACL6dYA2AgAJ" rel=3D"no=
follow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;javascript:&#39;;return true;">wka...@yahoo.com</a>=
&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ACL6dYA2AgAJ" 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;">std-pr...@is=
ocpp.org</a>&gt;</span> wrote:<br><div><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">For a class C, if the copy construct=
or is not deleted or suppressed, the default copy assignment operator shoul=
d be:<div><br></div><div>C &amp; operator =3D (const C &amp;that)</div><div=
>{</div><div>=C2=A0 if (&amp;that !=3D this)</div><div>=C2=A0 {</div><div>=
=C2=A0 =C2=A0 this-&gt;~C();</div><div>=C2=A0 =C2=A0 new (this) C(that);</d=
iv><div>=C2=A0 }</div><div>=C2=A0 return *this;</div><div>}</div><div><br><=
/div><div>(with const omitted from the parameter if it is omitted in the co=
py constructor).</div><div><br></div><div>Likewise, if the move constructor=
 is not deleted or surpressed, the default move assignment operator should =
be:</div><div><br></div><div><div>C &amp; operator =3D (C &amp;&amp;that)</=
div><div>{</div><div>=C2=A0 if (&amp;that !=3D this)</div><div>=C2=A0 {</di=
v><div>=C2=A0 =C2=A0 this-&gt;~C();</div><div>=C2=A0 =C2=A0 new (this) C(st=
d::move(that));</div><div>=C2=A0 }</div><div>=C2=A0 return *this;</div><div=
>}</div></div><div><br></div><div>Hypothetically this could break existing =
code, but I can&#39;t think of a practical example of useful code it would =
break.</div></div></blockquote><div><br></div><div>Only if you live in an e=
xception-free world...=C2=A0</div></div></div></div></blockquote><div><br><=
/div><div>Also, what happens if C is the base type of the object (this is t=
roublesome regardless of the destructor being virtual or not)? Bonus points=
 -- what if it has const or reference datamembers ;)<br></div><div><br></di=
v><div>I do agree, though, that in some idealized world this could be a sen=
sible default.</div><div><br></div><div>-- Matt Calabrese</div></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/d25df281-7c9a-4a58-ace4-9d0914836959%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d25df281-7c9a-4a58-ace4-9d0914836959=
%40isocpp.org</a>.<br />

------=_Part_4006_1441833072.1521833619960--

------=_Part_4005_1235032507.1521833619959--

.


Author: Todd Fleming <tbfleming@gmail.com>
Date: Fri, 23 Mar 2018 17:21:52 -0700 (PDT)
Raw View
------=_Part_4743_1772972159.1521850912482
Content-Type: multipart/alternative;
 boundary="----=_Part_4744_1163950017.1521850912482"

------=_Part_4744_1163950017.1521850912482
Content-Type: text/plain; charset="UTF-8"

On Friday, March 23, 2018 at 3:33:40 PM UTC-4, Walt Karas wrote:
>
> Can you elaborate on the problem with const and reference members?
>

Let's say you have this:

struct C {
    const int i;
    ...
};

void f(C& x)
{
    int i1 = x.i;
    g(x);
    int i2 = x.i;
    ...
}

It is currently impossible for g() to modify x.i without invoking undefined
behavior. This allows the compiler to assume i1 == i2. Under the proposed
rule, g(x) could assign to x, changing x.i in the process. See also
std::launder.

Todd

--
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/298d8094-369b-46e3-8b4a-3714c8130cbb%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 23, 2018 at 3:33:40 PM UTC-4, Walt Karas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Can you=
 elaborate on the problem with const and reference members?</div></blockquo=
te><div><br></div><div>Let&#39;s say you have this:</div><div><br></div><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> C </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">void<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">C</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> i1 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">i</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 g</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> i2 </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">...</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><div><br>It is curr=
ently impossible for g() to modify x.i without invoking undefined behavior.=
 This allows the compiler to assume i1 =3D=3D i2. Under the proposed rule, =
g(x) could assign to x, changing x.i in the process. See also std::launder.=
</div><div><br></div><div>Todd</div><div><br></div></div>

<p></p>

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

------=_Part_4744_1163950017.1521850912482--

------=_Part_4743_1772972159.1521850912482--

.


Author: ytqclys@gmail.com
Date: Fri, 23 Mar 2018 18:24:07 -0700 (PDT)
Raw View
------=_Part_4914_1104292510.1521854647162
Content-Type: multipart/alternative;
 boundary="----=_Part_4915_1019084700.1521854647162"

------=_Part_4915_1019084700.1521854647162
Content-Type: text/plain; charset="UTF-8"



On Friday, March 23, 2018 at 7:21:52 PM UTC-5, Todd Fleming wrote:
>
> On Friday, March 23, 2018 at 3:33:40 PM UTC-4, Walt Karas wrote:
>>
>> Can you elaborate on the problem with const and reference members?
>>
>
> Let's say you have this:
>
> struct C {
>     const int i;
>     ...
> };
>
> void f(C& x)
> {
>     int i1 = x.i;
>     g(x);
>     int i2 = x.i;
>     ...
> }
>
> It is currently impossible for g() to modify x.i without invoking
> undefined behavior. This allows the compiler to assume i1 == i2. Under the
> proposed rule, g(x) could assign to x, changing x.i in the process. See
> also std::launder.
>
> Todd
>
>
I guess the rule that the default is suppressed by const / reference data
members would have to be retained.

--
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/7aa832bb-5c6b-48ab-bc06-265271835909%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, March 23, 2018 at 7:21:52 PM UTC-5, Tod=
d Fleming wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Friday, March 23, 2018 at 3:33:40 PM UTC-4, Walt Karas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Can you elaborate on the p=
roblem with const and reference members?</div></blockquote><div><br></div><=
div>Let&#39;s say you have this:</div><div><br></div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008=
">struct</span><span style=3D"color:#000"> C </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">const</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> i</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color:#660">...</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br></s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#000"> f</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">C</span><s=
pan style=3D"color:#660">&amp;</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:#008">int</span><span style=3D"color:#000"> i1=
 </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> x<=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">i</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 g</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">x</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"=
color:#000"> i2 </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> x</span><span style=3D"color:#660">.</span><span style=3D"colo=
r:#000">i</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">...</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></div></code></div><div><br>It is currently impo=
ssible for g() to modify x.i without invoking undefined behavior. This allo=
ws the compiler to assume i1 =3D=3D i2. Under the proposed rule, g(x) could=
 assign to x, changing x.i in the process. See also std::launder.</div><div=
><br></div><div>Todd</div><div><br></div></div></blockquote><div><br></div>=
<div>I guess the rule that the default is suppressed by const / reference d=
ata members would have to be retained.=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/7aa832bb-5c6b-48ab-bc06-265271835909%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7aa832bb-5c6b-48ab-bc06-265271835909=
%40isocpp.org</a>.<br />

------=_Part_4915_1019084700.1521854647162--

------=_Part_4914_1104292510.1521854647162--

.


Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Fri, 23 Mar 2018 18:39:26 -0700 (PDT)
Raw View
------=_Part_4849_1004694340.1521855566874
Content-Type: multipart/alternative;
 boundary="----=_Part_4850_977227222.1521855566874"

------=_Part_4850_977227222.1521855566874
Content-Type: text/plain; charset="UTF-8"



On Friday, March 23, 2018 at 7:21:52 PM UTC-5, Todd Fleming wrote:
>
> On Friday, March 23, 2018 at 3:33:40 PM UTC-4, Walt Karas wrote:
>>
>> Can you elaborate on the problem with const and reference members?
>>
>
> Let's say you have this:
>
> struct C {
>     const int i;
>     ...
> };
>
> void f(C& x)
> {
>     int i1 = x.i;
>     g(x);
>     int i2 = x.i;
>     ...
> }
>
> It is currently impossible for g() to modify x.i without invoking
> undefined behavior. This allows the compiler to assume i1 == i2. Under the
> proposed rule, g(x) could assign to x, changing x.i in the process. See
> also std::launder.
>
> Todd
>
>
It seems that the current behavior (of suppressing the default assignment
operator if there are const or reference data member) would have to be kept.

--
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/1cde3d3e-b0e8-4a09-a0ef-569d7f5027dd%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, March 23, 2018 at 7:21:52 PM UTC-5, Tod=
d Fleming wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Friday, March 23, 2018 at 3:33:40 PM UTC-4, Walt Karas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Can you elaborate on the p=
roblem with const and reference members?</div></blockquote><div><br></div><=
div>Let&#39;s say you have this:</div><div><br></div><div style=3D"backgrou=
nd-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;=
border-width:1px;word-wrap:break-word"><code><div><span style=3D"color:#008=
">struct</span><span style=3D"color:#000"> C </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#008">const</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">int</span><span style=3D"color:#000"> i</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color:#660">...</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#660">};</span><span style=3D"color:#000"><br><br></s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#000"> f</sp=
an><span style=3D"color:#660">(</span><span style=3D"color:#000">C</span><s=
pan style=3D"color:#660">&amp;</span><span style=3D"color:#000"> x</span><s=
pan style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><spa=
n style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
 </span><span style=3D"color:#008">int</span><span style=3D"color:#000"> i1=
 </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> x<=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">i</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 =
=C2=A0 g</span><span style=3D"color:#660">(</span><span style=3D"color:#000=
">x</span><span style=3D"color:#660">);</span><span style=3D"color:#000"><b=
r>=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"=
color:#000"> i2 </span><span style=3D"color:#660">=3D</span><span style=3D"=
color:#000"> x</span><span style=3D"color:#660">.</span><span style=3D"colo=
r:#000">i</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660">...</span><span styl=
e=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span></div></code></div><div><br>It is currently impo=
ssible for g() to modify x.i without invoking undefined behavior. This allo=
ws the compiler to assume i1 =3D=3D i2. Under the proposed rule, g(x) could=
 assign to x, changing x.i in the process. See also std::launder.</div><div=
><br></div><div>Todd</div><div><br></div></div></blockquote><div><br></div>=
<div>It seems that the current behavior (of suppressing the default assignm=
ent operator if there are const or reference data member) would have to be =
kept.</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/1cde3d3e-b0e8-4a09-a0ef-569d7f5027dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1cde3d3e-b0e8-4a09-a0ef-569d7f5027dd=
%40isocpp.org</a>.<br />

------=_Part_4850_977227222.1521855566874--

------=_Part_4849_1004694340.1521855566874--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 23 Mar 2018 20:45:47 -0700 (PDT)
Raw View
------=_Part_5206_137954997.1521863148110
Content-Type: multipart/alternative;
 boundary="----=_Part_5207_613048554.1521863148110"

------=_Part_5207_613048554.1521863148110
Content-Type: text/plain; charset="UTF-8"

On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>
> It seems that the current behavior (of suppressing the default assignment
> operator if there are const or reference data member) would have to be kept.
>

So... what exactly is the purpose of this proposal? That's the thing I
don't really understand; what does this allow us to do now that we could
not before?

--
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/49d9bc4b-24fa-4bc1-afe1-98100fa81e8f%40isocpp.org.

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

<div dir=3D"ltr">On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It=
 seems that the current behavior (of suppressing the default assignment ope=
rator if there are const or reference data member) would have to be kept.</=
div></div></blockquote><div><br>So... what exactly is the purpose of this p=
roposal? That&#39;s the thing I don&#39;t really understand; what does this=
 allow us to do now that we could not before?<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/49d9bc4b-24fa-4bc1-afe1-98100fa81e8f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/49d9bc4b-24fa-4bc1-afe1-98100fa81e8f=
%40isocpp.org</a>.<br />

------=_Part_5207_613048554.1521863148110--

------=_Part_5206_137954997.1521863148110--

.


Author: Richard Hodges <hodges.r@gmail.com>
Date: Sat, 24 Mar 2018 07:33:14 +0000
Raw View
--000000000000c279510568238db3
Content-Type: text/plain; charset="UTF-8"

> It is currently impossible for g() to modify x.i without invoking
undefined behavior.

Good!!

Modifying x.i should be as impossible as the compiler can make it.

If you need it to be mutable, surely don't mark it const.


On 24 March 2018 at 03:45, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>>
>> It seems that the current behavior (of suppressing the default assignment
>> operator if there are const or reference data member) would have to be kept.
>>
>
> So... what exactly is the purpose of this proposal? That's the thing I
> don't really understand; what does this allow us to do now that we could
> not before?
>
> --
> 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/49d9bc4b-24fa-4bc1-
> afe1-98100fa81e8f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/49d9bc4b-24fa-4bc1-afe1-98100fa81e8f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

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

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

<div dir=3D"ltr">&gt;=C2=A0<span style=3D"color:rgb(34,34,34);font-family:a=
rial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:n=
ormal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-a=
lign:start;text-indent:0px;text-transform:none;white-space:normal;word-spac=
ing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;tex=
t-decoration-color:initial;float:none;display:inline">It is currently impos=
sible for g() to modify x.i without invoking undefined behavior.</span><div=
><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:=
12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:no=
rmal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px=
;text-transform:none;white-space:normal;word-spacing:0px;background-color:r=
gb(255,255,255);text-decoration-style:initial;text-decoration-color:initial=
;float:none;display:inline"><br></span></div><div><span style=3D"color:rgb(=
34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;f=
ont-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;lette=
r-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white=
-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decor=
ation-style:initial;text-decoration-color:initial;float:none;display:inline=
">Good!!=C2=A0</span></div><div><span style=3D"color:rgb(34,34,34);font-fam=
ily:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatu=
res:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;t=
ext-align:start;text-indent:0px;text-transform:none;white-space:normal;word=
-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initia=
l;text-decoration-color:initial;float:none;display:inline"><br></span></div=
><div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-=
size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-ca=
ps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px;background-co=
lor:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:in=
itial;float:none;display:inline">Modifying x.i should be as impossible as t=
he compiler can make it.</span></div><div><span style=3D"color:rgb(34,34,34=
);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-vari=
ant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacin=
g:normal;text-align:start;text-indent:0px;text-transform:none;white-space:n=
ormal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-st=
yle:initial;text-decoration-color:initial;float:none;display:inline"><br></=
span></div><div><span style=3D"font-size:12.8px">If you need it to be mutab=
le, surely don&#39;t mark it const.=C2=A0</span><br></div><div><span style=
=3D"font-size:12.8px"><br></span></div></div><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">On 24 March 2018 at 03:45, Nicol Bolas <span di=
r=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmck=
esson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><span class=3D"">On Friday, March 23, 2018 at 9:39:26 PM UTC-=
4, Walt Karas wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>It seems that the current behavior (of suppressing the default assig=
nment operator if there are const or reference data member) would have to b=
e kept.</div></div></blockquote></span><div><br>So... what exactly is the p=
urpose of this proposal? That&#39;s the thing I don&#39;t really understand=
; what does this allow us to do now that we could not before?<br></div></di=
v><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/49d9bc4b-24fa-4bc1-afe1-98100fa81e8f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/49d9=
bc4b-24fa-4bc1-<wbr>afe1-98100fa81e8f%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

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

--000000000000c279510568238db3--

.


Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 24 Mar 2018 05:37:33 -0700 (PDT)
Raw View
------=_Part_6301_575013284.1521895053887
Content-Type: multipart/alternative;
 boundary="----=_Part_6302_498166899.1521895053887"

------=_Part_6302_498166899.1521895053887
Content-Type: text/plain; charset="UTF-8"



On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
>
> On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>>
>> It seems that the current behavior (of suppressing the default assignment
>> operator if there are const or reference data member) would have to be kept.
>>
>
> So... what exactly is the purpose of this proposal? That's the thing I
> don't really understand; what does this allow us to do now that we could
> not before?
>

It's a convenience.  It think it would be very rare that it would not
result in the desired behavior for the assignment operators.

--
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/a148c6ab-780e-4cd3-9e7a-557b5ef99b38%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It seems that the cur=
rent behavior (of suppressing the default assignment operator if there are =
const or reference data member) would have to be kept.</div></div></blockqu=
ote><div><br>So... what exactly is the purpose of this proposal? That&#39;s=
 the thing I don&#39;t really understand; what does this allow us to do now=
 that we could not before?<br></div></div></blockquote><div><br></div><div>=
It&#39;s a convenience.=C2=A0 It think it would be very rare that it would =
not result in the desired behavior for the assignment operators.</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/a148c6ab-780e-4cd3-9e7a-557b5ef99b38%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a148c6ab-780e-4cd3-9e7a-557b5ef99b38=
%40isocpp.org</a>.<br />

------=_Part_6302_498166899.1521895053887--

------=_Part_6301_575013284.1521895053887--

.


Author: Edward Catmur <ed@catmur.co.uk>
Date: Sat, 24 Mar 2018 17:42:47 -0700 (PDT)
Raw View
------=_Part_8229_2018811114.1521938567821
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Saturday, 24 March 2018 12:37:34 UTC, Walt Karas  wrote:
> On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
> On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>=20
> It seems that the current behavior (of suppressing the default assignment=
 operator if there are const or reference data member) would have to be kep=
t.
>=20
> So... what exactly is the purpose of this proposal? That's the thing I do=
n't really understand; what does this allow us to do now that we could not =
before?
>=20
>=20
>=20
> It's a convenience.=C2=A0 It think it would be very rare that it would no=
t result in the desired behavior for the assignment operators.

But how would this be any more convenient than the current behavior of memb=
erwise assignment?

--=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/8d74a466-5781-4d02-abf8-c1681fb99871%40isocpp.or=
g.

------=_Part_8229_2018811114.1521938567821--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 25 Mar 2018 11:34:04 +0800
Raw View
On Sunday, 25 March 2018 08:42:47 CST Edward Catmur wrote:
> But how would this be any more convenient than the current behavior of
> memberwise assignment?

It would be a pessimisation for any type that indirectly uses pimpl.

struct C
{
 TypeWithPimpl d;
};

When C::operator=() gets called, according to the OP, it would run:
  if (&that != this)
  {
    this->~C();
    new (this) C(that);
  }
  return *this;

That means it calls d->~D(); then new (&d) D(that->d);

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



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

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 24 Mar 2018 21:00:53 -0700 (PDT)
Raw View
------=_Part_9055_569626877.1521950453891
Content-Type: multipart/alternative;
 boundary="----=_Part_9056_1556163374.1521950453891"

------=_Part_9056_1556163374.1521950453891
Content-Type: text/plain; charset="UTF-8"

On Saturday, March 24, 2018 at 8:37:34 AM UTC-4, Walt Karas wrote:
>
> On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
>>
>> On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>>>
>>> It seems that the current behavior (of suppressing the default
>>> assignment operator if there are const or reference data member) would have
>>> to be kept.
>>>
>>
>> So... what exactly is the purpose of this proposal? That's the thing I
>> don't really understand; what does this allow us to do now that we could
>> not before?
>>
>
> It's a convenience.
>

How is it more convenient? All you're doing is changing the code that the
compiler effectively generates. So what exactly does it make more
convenient? Please provide an example where one would have to code their
programs in an inconvenient way which this feature could allow us a more
convenient alternative.

It think it would be very rare that it would not result in the desired
> behavior for the assignment operators.
>

Well, Thaigo's Pimpl example pretty much ended that argument.

--
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/c2e44b93-4071-44b5-842f-ddc0d1dec64d%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, March 24, 2018 at 8:37:34 AM UTC-4, Walt Kara=
s 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 Fr=
iday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">On Friday, March 23, 2018 at 9:3=
9:26 PM UTC-4, Walt Karas wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>It seems that the current behavior (of suppressing the d=
efault assignment operator if there are const or reference data member) wou=
ld have to be kept.</div></div></blockquote><div><br>So... what exactly is =
the purpose of this proposal? That&#39;s the thing I don&#39;t really under=
stand; what does this allow us to do now that we could not before?<br></div=
></div></blockquote><div><br></div><div>It&#39;s a convenience.</div></div>=
</blockquote><div><br>How is it more convenient? All you&#39;re doing is ch=
anging the code that the compiler effectively generates. So what exactly do=
es it make more convenient? Please provide an example where one would have =
to code their programs in an inconvenient way which this feature could allo=
w us a more convenient alternative.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>It think it would be very rare tha=
t it would not result in the desired behavior for the assignment operators.=
</div></div></blockquote><div><br>Well, Thaigo&#39;s Pimpl example pretty m=
uch ended that argument.<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/c2e44b93-4071-44b5-842f-ddc0d1dec64d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c2e44b93-4071-44b5-842f-ddc0d1dec64d=
%40isocpp.org</a>.<br />

------=_Part_9056_1556163374.1521950453891--

------=_Part_9055_569626877.1521950453891--

.


Author: "'Walt Karas' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sun, 25 Mar 2018 06:54:27 -0700 (PDT)
Raw View
------=_Part_10131_1753281335.1521986067445
Content-Type: multipart/alternative;
 boundary="----=_Part_10132_1197760938.1521986067446"

------=_Part_10132_1197760938.1521986067446
Content-Type: text/plain; charset="UTF-8"

On Saturday, March 24, 2018 at 7:42:47 PM UTC-5, Edward Catmur wrote:
>
> On Saturday, 24 March 2018 12:37:34 UTC, Walt Karas  wrote:
> > On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
> > On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
> >
> > It seems that the current behavior (of suppressing the default
> assignment operator if there are const or reference data member) would have
> to be kept.
> >
> > So... what exactly is the purpose of this proposal? That's the thing I
> don't really understand; what does this allow us to do now that we could
> not before?
> >
> >
> >
> > It's a convenience.  It think it would be very rare that it would not
> result in the desired behavior for the assignment operators.
>
> But how would this be any more convenient than the current behavior of
> memberwise assignment?


Because it also handles the case where the constructor is not the default.
For example, it's doing deep copying.

--
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/2ae6f514-cef0-4a24-88ae-6b79b7ad1213%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, March 24, 2018 at 7:42:47 PM UTC-5, Edward Ca=
tmur wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Saturday, 24 Mar=
ch 2018 12:37:34 UTC, Walt Karas =C2=A0wrote:
<br>&gt; On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
<br>&gt; On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
<br>&gt;=20
<br>&gt; It seems that the current behavior (of suppressing the default ass=
ignment operator if there are const or reference data member) would have to=
 be kept.
<br>&gt;=20
<br>&gt; So... what exactly is the purpose of this proposal? That&#39;s the=
 thing I don&#39;t really understand; what does this allow us to do now tha=
t we could not before?
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; It&#39;s a convenience.=C2=A0 It think it would be very rare that =
it would not result in the desired behavior for the assignment operators.
<br>
<br>But how would this be any more convenient than the current behavior of =
memberwise assignment?</blockquote><div><br></div><div>Because it also hand=
les the case where the constructor is not the default.=C2=A0 For example, i=
t&#39;s doing deep copying.=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/2ae6f514-cef0-4a24-88ae-6b79b7ad1213%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2ae6f514-cef0-4a24-88ae-6b79b7ad1213=
%40isocpp.org</a>.<br />

------=_Part_10132_1197760938.1521986067446--

------=_Part_10131_1753281335.1521986067445--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Sun, 25 Mar 2018 22:09:19 +0800
Raw View
On Sunday, 25 March 2018 21:54:27 CST 'Walt Karas' via ISO C++ Standard -
Future Proposals wrote:
> Because it also handles the case where the constructor is not the default.
> For example, it's doing deep copying.

Which is exactly the case I argue that the member-wise assignment is better.

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



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

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 25 Mar 2018 08:18:10 -0700 (PDT)
Raw View
------=_Part_9124_2062243192.1521991090148
Content-Type: multipart/alternative;
 boundary="----=_Part_9125_1068172389.1521991090149"

------=_Part_9125_1068172389.1521991090149
Content-Type: text/plain; charset="UTF-8"

On Sunday, March 25, 2018 at 9:54:27 AM UTC-4, Walt Karas wrote:
>
> On Saturday, March 24, 2018 at 7:42:47 PM UTC-5, Edward Catmur wrote:
>>
>> On Saturday, 24 March 2018 12:37:34 UTC, Walt Karas  wrote:
>> > On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
>> > On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
>> >
>> > It seems that the current behavior (of suppressing the default
>> assignment operator if there are const or reference data member) would have
>> to be kept.
>> >
>> > So... what exactly is the purpose of this proposal? That's the thing I
>> don't really understand; what does this allow us to do now that we could
>> not before?
>> >
>> >
>> >
>> > It's a convenience.  It think it would be very rare that it would not
>> result in the desired behavior for the assignment operators.
>>
>> But how would this be any more convenient than the current behavior of
>> memberwise assignment?
>
>
> Because it also handles the case where the constructor is not the
> default.  For example, it's doing deep copying.
>

But deep copy assignment is a different operation from deep copy
construction. In deep copy assignment, you *do not want* to allocate a new
object the way you would have to for deep copy construction. It's silly to
deallocate the currently managed object just to create a new one.

Now yes, if you're managing some polymorphic type through a base class
pointer, then you'll have to destroy and `clone` it either way. But that's
hardly the only use case of deep copy semantics. There are plenty of deep
copy types that know exactly what object they contain, and all of them will
still have to provide an explicit copy/move assignment.

I don't think this case is common enough to create a language change. You
can just write the explicit copy/move assignment code for those cases where
it crops up.

--
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/6122679d-7c00-4c10-a682-e57eb0a10abd%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, March 25, 2018 at 9:54:27 AM UTC-4, Walt Karas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Satu=
rday, March 24, 2018 at 7:42:47 PM UTC-5, Edward Catmur wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex">On Saturday, 24 March 2018 12:37:34 UTC, Walt Ka=
ras =C2=A0wrote:
<br>&gt; On Friday, March 23, 2018 at 10:45:48 PM UTC-5, Nicol Bolas wrote:
<br>&gt; On Friday, March 23, 2018 at 9:39:26 PM UTC-4, Walt Karas wrote:
<br>&gt;=20
<br>&gt; It seems that the current behavior (of suppressing the default ass=
ignment operator if there are const or reference data member) would have to=
 be kept.
<br>&gt;=20
<br>&gt; So... what exactly is the purpose of this proposal? That&#39;s the=
 thing I don&#39;t really understand; what does this allow us to do now tha=
t we could not before?
<br>&gt;=20
<br>&gt;=20
<br>&gt;=20
<br>&gt; It&#39;s a convenience.=C2=A0 It think it would be very rare that =
it would not result in the desired behavior for the assignment operators.
<br>
<br>But how would this be any more convenient than the current behavior of =
memberwise assignment?</blockquote><div><br></div><div>Because it also hand=
les the case where the constructor is not the default.=C2=A0 For example, i=
t&#39;s doing deep copying.</div></div></blockquote><div><br>But deep copy =
assignment is a different operation from deep copy construction. In deep co=
py assignment, you <i>do not want</i> to allocate a new object the way you =
would have to for deep copy construction. It&#39;s silly to deallocate the =
currently managed object just to create a new one.<br><br>Now yes, if you&#=
39;re managing some polymorphic type through a base class pointer, then you=
&#39;ll have to destroy and `clone` it either way. But that&#39;s hardly th=
e only use case of deep copy semantics. There are plenty of deep copy types=
 that know exactly what object they contain, and all of them will still hav=
e to provide an explicit copy/move assignment.<br><br>I don&#39;t think thi=
s case is common enough to create a language change. You can just write the=
 explicit copy/move assignment code for those cases where it crops up.<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/6122679d-7c00-4c10-a682-e57eb0a10abd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6122679d-7c00-4c10-a682-e57eb0a10abd=
%40isocpp.org</a>.<br />

------=_Part_9125_1068172389.1521991090149--

------=_Part_9124_2062243192.1521991090148--

.