------=_Part_955_1137013920.1412818407491
Content-Type: text/plain; charset=UTF-8

I was watching one of the talks at cppcon and it occurred to me that there
might be a better way to handle the implicitly generated default
constructors, op=, and destructor.

Currently if a class has a destructor it still gets the compiler defaulted
copy(), copy=, move(), and move=. In most cases, this is a mistake. If you
define a destructor it usually means you are manually managing a resource
and in that case you almost always need to define the copy and move
operations yourself to carefully handle duplicating and transferring that
resource.

Therefore I would propose a change. Namely that if a class has a
non-default destructor, then copy(), copy=, move(), and move= are all
implicitly deleted.

This would break existing code. A lot of projects which switch to C++17
mode would all of the sudden fail to compile with these kinds of errors.
These bugs are easy to fix because you can just define the operations with
= default, but it could be a lot of annoying tedium to do so. Still, this
kind of break would give developers the opportunity to audit their code
base for types which manage resources but incorrectly have implicitly
defined copy and move operations.


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I was watching one of the talks at cppcon and it occurred =
to me that there might be a better way to handle the implicitly generated d=
efault constructors, op=3D, and destructor.<div><br></div><div>Currently if=
 a class has a destructor it still gets the compiler defaulted copy(), copy=
=3D, move(), and move=3D. In most cases, this is a mistake. If you define a=
 destructor it usually means you are manually managing a resource and in th=
at case you almost always need to define the copy and move operations yours=
elf to carefully handle duplicating and transferring that resource.</div><d=
iv><br></div><div>Therefore I would propose a change. Namely that if a clas=
s has a non-default destructor, then copy(), copy=3D, move(), and move=3D a=
re all implicitly deleted.</div><div><br></div><div>This would break existi=
ng code. A lot of projects which switch to C++17 mode would all of the sudd=
en fail to compile with these kinds of errors. These bugs are easy to fix b=
ecause you can just define the operations with =3D default, but it could be=
 a lot of annoying tedium to do so. Still, this kind of break would give de=
velopers the opportunity to audit their code base for types which manage re=
sources but incorrectly have implicitly defined copy and move operations.</=
div><div><br></div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_955_1137013920.1412818407491--

.

------=_Part_1074_2110223604.1412834828535
Content-Type: text/plain; charset=UTF-8

On Thursday, October 9, 2014 3:33:27 AM UTC+2, Matthew Fioravante wrote:
>
> I was watching one of the talks at cppcon and it occurred to me that there
> might be a better way to handle the implicitly generated default
> constructors, op=, and destructor.
>
> Currently if a class has a destructor it still gets the compiler defaulted
> copy(), copy=, move(), and move=. In most cases, this is a mistake. If you
> define a destructor it usually means you are manually managing a resource
> and in that case you almost always need to define the copy and move
> operations yourself to carefully handle duplicating and transferring that
> resource.
>

A user-declared destructor will make the move() and move= not-declared, and
the default generated copy() and copy= are deprecated as per [class.copy]/7
in N3797. Clang (but not gcc!) warns against it. See slide 24 of
http://accu.org/content/conf2014/Howard_Hinnant_Accu_2014.pdf

class Test
{
public:
    virtual ~Test() = default;
};

int main()
{
    Test t;
    auto s = t; // warning: definition of implicit copy constructor for
'Test' is
                // deprecated because it has a user-declared destructor
[-Wdeprecated]
}

Live Example on Coliru: http://coliru.stacked-crooked.com/a/45c4f3b3c5447dca

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, October 9, 2014 3:33:27 AM UTC+2, Matthew Fio=
ravante 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"=
>I was watching one of the talks at cppcon and it occurred to me that there=
 might be a better way to handle the implicitly generated default construct=
ors, op=3D, and destructor.<div><br></div><div>Currently if a class has a d=
estructor it still gets the compiler defaulted copy(), copy=3D, move(), and=
 move=3D. In most cases, this is a mistake. If you define a destructor it u=
sually means you are manually managing a resource and in that case you almo=
st always need to define the copy and move operations yourself to carefully=
 handle duplicating and transferring that resource.</div></div></blockquote=
><div><br></div><div>A user-declared destructor will make the move() and mo=
ve=3D not-declared, and the default generated copy() and copy=3D are deprec=
ated as per [class.copy]/7 in N3797. Clang (but not gcc!) warns against it.=
 See slide 24 of http://accu.org/content/conf2014/Howard_Hinnant_Accu_2014.=
pdf&nbsp;</div><div><br></div><div><div><font color=3D"#0000ff" face=3D"cou=
rier new, monospace">class Test</font></div><div><font color=3D"#0000ff" fa=
ce=3D"courier new, monospace">{</font></div><div><font color=3D"#0000ff" fa=
ce=3D"courier new, monospace">public: &nbsp; &nbsp;</font></div><div><font =
color=3D"#0000ff" face=3D"courier new, monospace">&nbsp; &nbsp; virtual ~Te=
st() =3D default; &nbsp; &nbsp; &nbsp;&nbsp;</font></div><div><font color=
=3D"#0000ff" face=3D"courier new, monospace">};</font></div><div><font colo=
r=3D"#0000ff" face=3D"courier new, monospace"><br></font></div><div><font c=
olor=3D"#0000ff" face=3D"courier new, monospace">int main()</font></div><di=
v><font color=3D"#0000ff" face=3D"courier new, monospace">{</font></div><di=
v><font color=3D"#0000ff" face=3D"courier new, monospace">&nbsp; &nbsp; Tes=
t t;</font></div><div><font color=3D"#0000ff" face=3D"courier new, monospac=
e">&nbsp; &nbsp; auto s =3D t; // warning: definition of implicit copy cons=
tructor for 'Test' is</font></div><div><font color=3D"#0000ff" face=3D"cour=
ier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 // deprecated because it has a user-declared destructor [-Wdeprecated]</fo=
nt></div><div><font color=3D"#0000ff" face=3D"courier new, monospace">}</fo=
nt></div></div><div><br></div><div>Live Example on Coliru: http://coliru.st=
acked-crooked.com/a/45c4f3b3c5447dca<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1074_2110223604.1412834828535--

.

On 9 October 2014 09:07,  <rhalbersma@gmail.com> wrote:
> On Thursday, October 9, 2014 3:33:27 AM UTC+2, Matthew Fioravante wrote:
>> Currently if a class has a destructor it still gets the compiler defaulted
>> copy(), copy=, move(), and move=. In most cases, this is a mistake. If you
>> define a destructor it usually means you are manually managing a resource
>> and in that case you almost always need to define the copy and move
>> operations yourself to carefully handle duplicating and transferring that
>> resource.
> A user-declared destructor will make the move() and move= not-declared, and

Correct.

> the default generated copy() and copy= are deprecated as per [class.copy]/7

Ditto.

> in N3797. Clang (but not gcc!) warns against it. See slide 24 of
> http://accu.org/content/conf2014/Howard_Hinnant_Accu_2014.pdf

We have reports from other implementation vendors that they can't warn about
generated copy operations in the presence of a user-declared destructor because
it breaks too much code.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Oct 9, 2014 at 8:12 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> We have reports from other implementation vendors that they can't warn
> about
> generated copy operations in the presence of a user-declared destructor
> because
> it breaks too much code.


In Clang, you have to work really hard to break such code: only
-Wdeprecated or the draconian -Weverything will trigger the warning.
Not even -Wall -pedantic will trigger it.

But as a matter of principle, since the Standard deprecates it, vendors
should warn against it, and users should fix their code.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c36e32ab546e0504f76472
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, Oct 9, 2014 at 8:12 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@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">We have =
reports from other implementation vendors that they can&#39;t warn about<br=
>
generated copy operations in the presence of a user-declared destructor bec=
ause<br>
it breaks too much code.</blockquote><div><br></div><div>In Clang, you have=
 to work really hard to break such code: only -Wdeprecated or the draconian=
 -Weverything will trigger the warning.=C2=A0</div><div>Not even -Wall -ped=
antic will trigger it.=C2=A0</div><div><br></div><div>But as a matter of pr=
inciple, since the Standard deprecates it, vendors should warn against it, =
and users should fix their code.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c36e32ab546e0504f76472--

.

On 9 October 2014 09:17, Rein Halbersma <rhalbersma@gmail.com> wrote:
>> We have reports from other implementation vendors that they can't warn
>> about
>> generated copy operations in the presence of a user-declared destructor
>> because
>> it breaks too much code.
> In Clang, you have to work really hard to break such code: only -Wdeprecated
> or the draconian -Weverything will trigger the warning.
> Not even -Wall -pedantic will trigger it.
> But as a matter of principle, since the Standard deprecates it, vendors
> should warn against it, and users should fix their code.

The standard places no such requirement nor even a request for implementation
vendors. But if people really think that's the expected outcome, we perhaps
should un-deprecate the generation of copy operations in the presence of
user-declared destructors.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Oct 9, 2014 at 8:21 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 9 October 2014 09:17, Rein Halbersma <rhalbersma@gmail.com> wrote:
> >> We have reports from other implementation vendors that they can't warn
> >> about
> >> generated copy operations in the presence of a user-declared destructor
> >> because
> >> it breaks too much code.
> > In Clang, you have to work really hard to break such code: only
> -Wdeprecated
> > or the draconian -Weverything will trigger the warning.
> > Not even -Wall -pedantic will trigger it.
> > But as a matter of principle, since the Standard deprecates it, vendors
> > should warn against it, and users should fix their code.
>
> The standard places no such requirement nor even a request for
> implementation
> vendors.


Of course you are right, there is no requirement that vendors "should" (in
the ISO/IEC sense) warn against deprecated features. OTOH, vendors already
"may" (as per [depr]/2) use the [[deprecated]] attribute for such library
components. So I don't find Clang's easy to disable warning onerous on me
as a user. On the contrary, I find it helpful to guide me towards
future-proof code. Perhaps an upcoming version of clang-modernize will even
fix this for me automatically.


> But if people really think that's the expected outcome, we perhaps
> should un-deprecate the generation of copy operations in the presence of
> user-declared destructors.


I think it's entirely reasonable that users are forced to explicitly
default their copy/move members in the presence of a user-declared
destructor. It's merely an educational matter to make them aware of that,
and vendors warning aganist it at the highest -yet still overridable-
warning levels really helps in that respect.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c36e3288bd070504f7a9fe
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, Oct 9, 2014 at 8:21 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@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"><span cl=
ass=3D"">On 9 October 2014 09:17, Rein Halbersma &lt;<a href=3D"mailto:rhal=
bersma@gmail.com">rhalbersma@gmail.com</a>&gt; wrote:<br>
&gt;&gt; We have reports from other implementation vendors that they can&#3=
9;t warn<br>
&gt;&gt; about<br>
&gt;&gt; generated copy operations in the presence of a user-declared destr=
uctor<br>
&gt;&gt; because<br>
&gt;&gt; it breaks too much code.<br>
&gt; In Clang, you have to work really hard to break such code: only -Wdepr=
ecated<br>
&gt; or the draconian -Weverything will trigger the warning.<br>
&gt; Not even -Wall -pedantic will trigger it.<br>
&gt; But as a matter of principle, since the Standard deprecates it, vendor=
s<br>
&gt; should warn against it, and users should fix their code.<br>
<br>
</span>The standard places no such requirement nor even a request for imple=
mentation<br>
vendors. </blockquote><div><br></div><div>Of course you are right, there is=
 no requirement that vendors &quot;should&quot; (in the ISO/IEC sense) warn=
 against deprecated features. OTOH, vendors already &quot;may&quot; (as per=
 [depr]/2) use the [[deprecated]] attribute for such library components. So=
 I don&#39;t find Clang&#39;s easy to disable warning onerous on me as a us=
er. On the contrary, I find it helpful to guide me towards future-proof cod=
e. Perhaps an upcoming version of clang-modernize will even fix this for me=
 automatically.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But if=
 people really think that&#39;s the expected outcome, we perhaps<br>
should un-deprecate the generation of copy operations in the presence of<br=
>
user-declared destructors.</blockquote><div><br></div><div>I think it&#39;s=
 entirely reasonable that users are forced to explicitly default their copy=
/move members in the presence of a user-declared destructor. It&#39;s merel=
y an educational matter to make them aware of that, and vendors warning aga=
nist it at the highest -yet still overridable- warning levels really helps =
in that respect.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c36e3288bd070504f7a9fe--

.

On 9 October 2014 09:37, Rein Halbersma <rhalbersma@gmail.com> wrote:
> Of course you are right, there is no requirement that vendors "should" (in
> the ISO/IEC sense) warn against deprecated features. OTOH, vendors already
> "may" (as per [depr]/2) use the [[deprecated]] attribute for such library
> components. So I don't find Clang's easy to disable warning onerous on me as

This is not about library components, but a deprecated language facility.

>> But if people really think that's the expected outcome, we perhaps
>> should un-deprecate the generation of copy operations in the presence of
>> user-declared destructors.
> I think it's entirely reasonable that users are forced to explicitly default
> their copy/move members in the presence of a user-declared destructor. It's

The problem there is that the existing code that would generate such diagnostics
often still needs to be built as C++03, so users can't just default
copy members,
they need to macro them.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Oct 9, 2014 at 8:50 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 9 October 2014 09:37, Rein Halbersma <rhalbersma@gmail.com> wrote:
> > Of course you are right, there is no requirement that vendors "should"
> (in
> > the ISO/IEC sense) warn against deprecated features. OTOH, vendors
> already
> > "may" (as per [depr]/2) use the [[deprecated]] attribute for such library
> > components. So I don't find Clang's easy to disable warning onerous on
> me as
>
> This is not about library components, but a deprecated language facility.


I know, my point was that I would find it entirely reasonable if the
Standard would recommend -not mandate- vendors to warn about deprecated
langauge facilities ("should warn", not "shall warn").

For library features, I would also be in favor of changing [depr]/2 to "An
implementation *should* declare library names and entities described in
this section with the deprecated attribute". Again, "should" instead of
"may", not "shall".


> >> But if people really think that's the expected outcome, we perhaps
> >> should un-deprecate the generation of copy operations in the presence of
> >> user-declared destructors.
> > I think it's entirely reasonable that users are forced to explicitly
> default
> > their copy/move members in the presence of a user-declared destructor.
> It's
>
> The problem there is that the existing code that would generate such
> diagnostics
> often still needs to be built as C++03, so users can't just default
> copy members,
> they need to macro them.


With clang -std=c++98 there is no such warning and there would be nothing
to fix. I don't see any reason to backport warnings about deprecated
features from c++11/14 to c++98/03. Users would eventually get the warning
when they start compiling under c++11/14 and then they can start using
=default (by hand or automatically with the proper modernize tools) to fix
the warnings.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c36436e68f2d0504f82cb2
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, Oct 9, 2014 at 8:50 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span class=3D"">On 9 =
October 2014 09:37, Rein Halbersma &lt;<a href=3D"mailto:rhalbersma@gmail.c=
om">rhalbersma@gmail.com</a>&gt; wrote:<br>
&gt; Of course you are right, there is no requirement that vendors &quot;sh=
ould&quot; (in<br>
&gt; the ISO/IEC sense) warn against deprecated features. OTOH, vendors alr=
eady<br>
&gt; &quot;may&quot; (as per [depr]/2) use the [[deprecated]] attribute for=
 such library<br>
&gt; components. So I don&#39;t find Clang&#39;s easy to disable warning on=
erous on me as<br>
<br>
</span>This is not about library components, but a deprecated language faci=
lity.</blockquote><div><br></div><div>I know, my point was that I would fin=
d it entirely reasonable if the Standard would recommend -not mandate- vend=
ors to warn about deprecated langauge facilities (&quot;should warn&quot;, =
not &quot;shall warn&quot;).=C2=A0</div><div><br></div><div>For library fea=
tures, I would also be in favor of changing [depr]/2 to &quot;An implementa=
tion <b>should</b> declare library names and entities described in this sec=
tion with the deprecated attribute&quot;. Again, &quot;should&quot; instead=
 of &quot;may&quot;, not &quot;shall&quot;.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span class=3D"">
&gt;&gt; But if people really think that&#39;s the expected outcome, we per=
haps<br>
&gt;&gt; should un-deprecate the generation of copy operations in the prese=
nce of<br>
&gt;&gt; user-declared destructors.<br>
&gt; I think it&#39;s entirely reasonable that users are forced to explicit=
ly default<br>
&gt; their copy/move members in the presence of a user-declared destructor.=
 It&#39;s<br>
<br>
</span>The problem there is that the existing code that would generate such=
 diagnostics<br>
often still needs to be built as C++03, so users can&#39;t just default<br>
copy members,<br>
they need to macro them.</blockquote><div><br></div><div>With clang -std=3D=
c++98 there is no such warning and there would be nothing to fix. I don&#39=
;t see any reason to backport warnings about deprecated features from c++11=
/14 to c++98/03. Users would eventually get the warning when they start com=
piling under c++11/14 and then they can start using =3Ddefault (by hand or =
automatically with the proper modernize tools) to fix the warnings.</div></=
div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c36436e68f2d0504f82cb2--

.

On 9 October 2014 10:13, Rein Halbersma <rhalbersma@gmail.com> wrote:
>> > I think it's entirely reasonable that users are forced to explicitly
>> > default
>> > their copy/move members in the presence of a user-declared destructor.
>> > It's
>> The problem there is that the existing code that would generate such
>> diagnostics
>> often still needs to be built as C++03, so users can't just default
>> copy members,
>> they need to macro them.
> With clang -std=c++98 there is no such warning and there would be nothing to
> fix. I don't see any reason to backport warnings about deprecated features
> from c++11/14 to c++98/03. Users would eventually get the warning when they
> start compiling under c++11/14 and then they can start using =default (by
> hand or automatically with the proper modernize tools) to fix the warnings.


And if users start using =default, their code will no longer compile as C++03,
so they need to hide the defaulting behind a macro, as I said. We would be
placing that burden on existing and _valid_ code, and not for a very good
reason.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_9E18173F-1746-451D-9EDC-A1A1EC2CB651
Content-Type: text/plain; charset=ISO-8859-1


On 2014-10-09, at 3:25 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> And if users start using =default, their code will no longer compile as C++03,
> so they need to hide the defaulting behind a macro, as I said. We would be
> placing that burden on existing and _valid_ code, and not for a very good
> reason.

For the general sake of evolution, it would be nice to have compilers that could switch dialects within a TU on the fly.

Pie in the sky maybe, but could it hurt to reserve extern "C++XY" language linkages (for all digits X, Y), and define them to change semantics but not ABI, under conditional support?

I'm not saying applying such a solution to a real project would be trivial either, but it's far more tractable than rewriting or macro'fying legacy code or abandoned libraries.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_9E18173F-1746-451D-9EDC-A1A1EC2CB651
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10&ndash;09, at 3:25 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">And if user=
s start using =3Ddefault, their code will no longer compile as C++03,<br>so=
 they need to hide the defaulting behind a macro, as I said. We would be<br=
>placing that burden on existing and _valid_ code, and not for a very good<=
br>reason.<br></blockquote></div><br><div>For the general sake of evolution=
, it would be nice to have compilers that could switch dialects within a TU=
 on the fly.</div><div><br></div><div>Pie in the sky maybe, but could it hu=
rt to reserve&nbsp;<font face=3D"Courier">extern "C++XY"</font> language li=
nkages (for all digits X, Y), and define them to change semantics but <i>no=
t</i>&nbsp;ABI, under conditional support?</div><div><br></div><div>I&rsquo=
;m not saying applying such a solution to a real project would be trivial e=
ither, but it&rsquo;s far more tractable than rewriting or macro&rsquo;fyin=
g legacy code or abandoned libraries.</div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_9E18173F-1746-451D-9EDC-A1A1EC2CB651--

.

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

On Thu, Oct 9, 2014 at 9:25 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 9 October 2014 10:13, Rein Halbersma <rhalbersma@gmail.com> wrote:
> > With clang -std=c++98 there is no such warning and there would be
> nothing to
> > fix. I don't see any reason to backport warnings about deprecated
> features
> > from c++11/14 to c++98/03. Users would eventually get the warning when
> they
> > start compiling under c++11/14 and then they can start using =default (by
> > hand or automatically with the proper modernize tools) to fix the
> warnings.
>
> And if users start using =default, their code will no longer compile as
> C++03,
> so they need to hide the defaulting behind a macro, as I said. We would be
> placing that burden on existing and _valid_ code, and not for a very good
> reason.


Yes, code that wants to support valid C++03 and also compile cleanly with
clang -Wdeprecated -std=c++14 would need a macro. However, there currently
is no *obligation* (and I only proposed a *recommendation* to warn against
it) to compile with -Wdeprecated. Valid C++03 code will continue to compile
under modern compilers at high warning levels until said feature is
actually removed in some future version of the Standard.

Users have plenty of choices:

1) -Wall -pedantic -std=c++14 will continue to support currently valid C++03
2) adding -Wdeprecated will require either
a) dropping C++03 support and adding =default copy functions
b) keeping C++03 support and adding a macro to hide the =default

Choice 2b) may not be optimal, but there is always option 1).

One can legitimately disagree about whether this particular facility was
justifiably deprecated. That is one issue. The other issue is about the
desirability of warnings for deprecated features. Given deprecation, I
really like that clang offers me a specific warning (one that I need to
expressly enable, because not even -Wall -pedantic includes it) about
possible future removal of such a feature.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113489149a8bd10504f9ca98
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, Oct 9, 2014 at 9:25 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@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"><span cl=
ass=3D"">On 9 October 2014 10:13, Rein Halbersma &lt;<a href=3D"mailto:rhal=
bersma@gmail.com">rhalbersma@gmail.com</a>&gt; wrote:<br>&gt; With clang -s=
td=3Dc++98 there is no such warning and there would be nothing to<br>
&gt; fix. I don&#39;t see any reason to backport warnings about deprecated =
features<br>
&gt; from c++11/14 to c++98/03. Users would eventually get the warning when=
 they<br>
&gt; start compiling under c++11/14 and then they can start using =3Ddefaul=
t (by<br>
&gt; hand or automatically with the proper modernize tools) to fix the warn=
ings.<br><br>
</span>And if users start using =3Ddefault, their code will no longer compi=
le as C++03,<br>
so they need to hide the defaulting behind a macro, as I said. We would be<=
br>
placing that burden on existing and _valid_ code, and not for a very good<b=
r>
reason.</blockquote></div><br></div><div class=3D"gmail_extra">Yes, code th=
at wants to support valid C++03 and also compile cleanly with clang -Wdepre=
cated -std=3Dc++14 would need a macro. However, there currently is no *obli=
gation* (and I only proposed a *recommendation* to warn against it) to comp=
ile with -Wdeprecated. Valid C++03 code will continue to compile under mode=
rn compilers at high warning levels until said feature is actually removed =
in some future version of the Standard.=C2=A0</div><div class=3D"gmail_extr=
a"><br></div><div class=3D"gmail_extra">Users have plenty of choices:</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1) -Wall -p=
edantic -std=3Dc++14 will continue to support currently valid C++03</div><d=
iv class=3D"gmail_extra">2) adding -Wdeprecated will require either</div><d=
iv class=3D"gmail_extra">a) dropping C++03 support and adding =3Ddefault co=
py functions</div><div class=3D"gmail_extra">b) keeping C++03 support and a=
dding a macro to hide the =3Ddefault=C2=A0</div><div class=3D"gmail_extra">=
<br></div><div class=3D"gmail_extra">Choice 2b) may not be optimal, but the=
re is always option 1).</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">One can legitimately disagree about whether this particul=
ar facility was justifiably deprecated. That is one issue. The other issue =
is about the desirability of warnings for deprecated features. Given deprec=
ation, I really like that clang offers me a specific warning (one that I ne=
ed to expressly enable, because not even -Wall -pedantic includes it) about=
 possible future removal of such a feature.=C2=A0<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113489149a8bd10504f9ca98--

.

On 9 October 2014 10:35, David Krauss <potswa@gmail.com> wrote:
> For the general sake of evolution, it would be nice to have compilers that
> could switch dialects within a TU on the fly.
> Pie in the sky maybe, but could it hurt to reserve extern "C++XY" language
> linkages (for all digits X, Y), and define them to change semantics but not
> ABI, under conditional support?


That sounds like some previous suggestions for (inline) namespaces that
change the language dialect within them. I don't expect it to be difficult
to find people who are opposed to such ideas..

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 9 October 2014 12:09, Rein Halbersma <rhalbersma@gmail.com> wrote:
> Yes, code that wants to support valid C++03 and also compile cleanly with
> clang -Wdeprecated -std=c++14 would need a macro. However, there currently
> is no *obligation* (and I only proposed a *recommendation* to warn against
> it) to compile with -Wdeprecated. Valid C++03 code will continue to compile
> under modern compilers at high warning levels until said feature is actually
> removed in some future version of the Standard.
>
> Users have plenty of choices:
>
> 1) -Wall -pedantic -std=c++14 will continue to support currently valid C++03
> 2) adding -Wdeprecated will require either
> a) dropping C++03 support and adding =default copy functions
> b) keeping C++03 support and adding a macro to hide the =default
>
> Choice 2b) may not be optimal, but there is always option 1).
>
> One can legitimately disagree about whether this particular facility was
> justifiably deprecated. That is one issue. The other issue is about the
> desirability of warnings for deprecated features. Given deprecation, I
> really like that clang offers me a specific warning (one that I need to
> expressly enable, because not even -Wall -pedantic includes it) about
> possible future removal of such a feature.


Well, users have the choices you enumerated without having to strengthen
anything the standard says, so it seems like you're not exactly advocating
a change in the standard.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-10-09, at 5:41 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

> On 9 October 2014 10:35, David Krauss <potswa@gmail.com> wrote:
>> For the general sake of evolution, it would be nice to have compilers that
>> could switch dialects within a TU on the fly.
>> Pie in the sky maybe, but could it hurt to reserve extern "C++XY" language
>> linkages (for all digits X, Y), and define them to change semantics but not
>> ABI, under conditional support?
>
> That sounds like some previous suggestions for (inline) namespaces that
> change the language dialect within them. I don't expect it to be difficult
> to find people who are opposed to such ideas..

Except my suggestion is already conforming. Its only normative change is to forbid such a language linkage string from selecting an old ABI.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Oct 9, 2014 at 11:44 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 9 October 2014 12:09, Rein Halbersma <rhalbersma@gmail.com> wrote:
> >  Users have plenty of choices:
> >
> > 1) -Wall -pedantic -std=c++14 will continue to support currently valid
> C++03
> > 2) adding -Wdeprecated will require either
> > a) dropping C++03 support and adding =default copy functions
> > b) keeping C++03 support and adding a macro to hide the =default
> >
> > Choice 2b) may not be optimal, but there is always option 1).
>
> Well, users have the choices you enumerated without having to strengthen
> anything the standard says, so it seems like you're not exactly advocating
> a change in the standard.


Except that path 1) will surprise users if and when a deprecated feature is
actually removed in a future standard. A warning will prepare them for
this. The change I'm advocationg is to change "may warn" for deprecated
library features to "should warn" for all library and language features.
But you are right, it's not a big issue and clang does what I want. <shrug>.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c36e32767b2c0504fbda38
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, Oct 9, 2014 at 11:44 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 9 October 2014 12:09, Rein Halbersma &lt;<a href=3D"mailto:rha=
lbersma@gmail.com">rhalbersma@gmail.com</a>&gt; wrote:<br>
&gt; =C2=A0Users have plenty of choices:<br>
&gt;<br>
&gt; 1) -Wall -pedantic -std=3Dc++14 will continue to support currently val=
id C++03<br>
&gt; 2) adding -Wdeprecated will require either<br>
&gt; a) dropping C++03 support and adding =3Ddefault copy functions<br>
&gt; b) keeping C++03 support and adding a macro to hide the =3Ddefault<br>
&gt;<br>
&gt; Choice 2b) may not be optimal, but there is always option 1).<br><br>
</span>Well, users have the choices you enumerated without having to streng=
then<br>
anything the standard says, so it seems like you&#39;re not exactly advocat=
ing<br>
a change in the standard.</blockquote><div><br></div><div>Except that path =
1) will surprise users if and when a deprecated feature is actually removed=
 in a future standard. A warning will prepare them for this. The change I&#=
39;m advocationg is to change &quot;may warn&quot; for deprecated library f=
eatures to &quot;should warn&quot; for all library and language features. B=
ut you are right, it&#39;s not a big issue and clang does what I want. &lt;=
shrug&gt;.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c36e32767b2c0504fbda38--

.

------=_Part_117_1925231147.1412891408981
Content-Type: text/plain; charset=UTF-8

On Thursday, October 9, 2014 8:12:59 AM UTC+2, Ville Voutilainen wrote:
>
> We have reports from other implementation vendors that they can't warn
> about
> generated copy operations in the presence of a user-declared destructor
> because
> it breaks too much code.
>

Do you mean they can't enable the warning by default?
Not being able to warn at all seems weird.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, October 9, 2014 8:12:59 AM UTC+2, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">We have reports f=
rom other implementation vendors that they can't warn about
<br>generated copy operations in the presence of a user-declared destructor=
 because
<br>it breaks too much code.
<br></blockquote><div><br></div><div>Do you mean they can't enable the warn=
ing by default?</div><div>Not being able to warn at all seems weird.&nbsp;<=
/div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_117_1925231147.1412891408981--

.

On 10 October 2014 00:50, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thursday, October 9, 2014 8:12:59 AM UTC+2, Ville Voutilainen wrote:
>>
>> We have reports from other implementation vendors that they can't warn
>> about
>> generated copy operations in the presence of a user-declared destructor
>> because
>> it breaks too much code.
>
>
> Do you mean they can't enable the warning by default?
> Not being able to warn at all seems weird.


They can't enable the warning under any existing warning flags.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Oct 9, 2014 at 2:12 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> > A user-declared destructor will make the move() and move= not-declared,
> and
>
> Correct.
>
> > the default generated copy() and copy= are deprecated as per
> [class.copy]/7
>
> Ditto.
>
>
These actually overkill, because sometimes ~T() = default; is required,
but those member functions are got deleted.  Cases:

  1. unique_ptr<IncompleteType>;  for pimpl for example, then I have
    to write all the code used to be generated by the compiler;
  2. virtual ~T() = default;  Same.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thu, Oct 9, 2014 at 2:12 AM, Ville Voutilainen <span di=
r=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bla=
nk">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">&gt; A user-declared destructor will make the move() and move=3D n=
ot-declared, and<br>
<br>
</span>Correct.<br>
<span class=3D""><br>
&gt; the default generated copy() and copy=3D are deprecated as per [class.=
copy]/7<br>
<br>
</span>Ditto.<br>
<span class=3D""></span><br></blockquote></div><br></div><div class=3D"gmai=
l_extra">These actually overkill, because sometimes ~T() =3D default; is re=
quired,<br></div><div class=3D"gmail_extra">but those member functions are =
got deleted.=C2=A0 Cases:<br><br></div><div class=3D"gmail_extra">=C2=A0 1.=
 unique_ptr&lt;IncompleteType&gt;;=C2=A0 for pimpl for example, then I have=
<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 to write all the co=
de used to be generated by the compiler;<br></div><div class=3D"gmail_extra=
">=C2=A0 2. virtual ~T() =3D default;=C2=A0 Same.<br clear=3D"all"></div><d=
iv class=3D"gmail_extra"><br>-- <br>Zhihao Yuan, ID lichray<br>The best way=
 to predict the future is to invent it.<br>________________________________=
___________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D=
"_blank">http://bit.ly/blog4bsd</a>
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec547c87feb69a9050504982f--

.

On 10 October 2014 01:03, Zhihao Yuan <zy@miator.net> wrote:
> On Thu, Oct 9, 2014 at 2:12 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> > A user-declared destructor will make the move() and move= not-declared,
>> > and
>>
>> Correct.
>>
>> > the default generated copy() and copy= are deprecated as per
>> > [class.copy]/7
>>
>> Ditto.
> These actually overkill, because sometimes ~T() = default; is required,
> but those member functions are got deleted.  Cases:

You're 4 years late. It was decided two meetings before the C++11 FDIS went out
that any user-declared destructor, even a defaulted one, will suppress
move operations.

>   1. unique_ptr<IncompleteType>;  for pimpl for example, then I have
>     to write all the code used to be generated by the compiler;

No you don't, you can still =default the move operations.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Thu, Oct 9, 2014 at 6:16 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
> >   1. unique_ptr<IncompleteType>;  for pimpl for example, then I have
> >     to write all the code used to be generated by the compiler;
>
> No you don't, you can still =default the move operations.
>
>
Ah, that works.  Thanks.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thu, Oct 9, 2014 at 6:16 PM, Ville Voutilainen <span di=
r=3D"ltr">&lt;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bla=
nk">ville.voutilainen@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><br>
&gt;=C2=A0 =C2=A01. unique_ptr&lt;IncompleteType&gt;;=C2=A0 for pimpl for e=
xample, then I have<br>
&gt;=C2=A0 =C2=A0 =C2=A0to write all the code used to be generated by the c=
ompiler;<br>
<br>
</span>No you don&#39;t, you can still =3Ddefault the move operations.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote></div>=
<br></div><div class=3D"gmail_extra">Ah, that works.=C2=A0 Thanks.<br clear=
=3D"all"></div><div class=3D"gmail_extra"><br>-- <br>Zhihao Yuan, ID lichra=
y<br>The best way to predict the future is to invent it.<br>_______________=
____________________________________<br>4BSD -- <a href=3D"http://bit.ly/bl=
og4bsd" target=3D"_blank">http://bit.ly/blog4bsd</a>
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3678c7505b50505055688--

.