Topic: Continuing with "auto" and destructors
Author: Johannes Schaub <schaub.johannes@googlemail.com>
Date: Tue, 24 Dec 2013 01:11:11 +0100
Raw View
Now that in C++14 we will have
x -> ~auto()
Why not allow that notion when declaring the destructor aswell? And
why not also for the constructor?
struct A {
auto() { }
~auto() { }
};
Thanks!
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 24 Dec 2013 08:30:38 +0800
Raw View
On 12/24/13 8:11 AM, Johannes Schaub wrote:
> Now that in C++14 we will have
>
> x -> ~auto()
News to me. How is this allowed? Referring to N3797, I don't see any
provision in the grammar of 5.2 [expr.post], or in 5.2.5 [expr.pseudo]
or 7.1.6.4 [dcl.spec.auto] which explicitly limits usage of auto.
> Why not allow that notion when declaring the destructor aswell? And
> why not also for the constructor?
>
> struct A {
> auto() { }
> ~auto() { }
> };
>
Because it looks like nonsense. It would be more expressive to allow
such for decltype(*this), but alas it would be a breaking change because
that refers to the enclosing class in a local class within a nonstatic
member function.
Also, constructors and destructors cannot be declared using typedef
names or other type-ids; this is already explicitly forbidden.
It would be nice to otherwise provide universal syntax for "the
enclosing class."
--
---
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/.
.
Author: Troy Heron <troy.heron@hixxy.org>
Date: Tue, 24 Dec 2013 11:53:41 +1000
Raw View
--047d7b6783f690699004ee3e0300
Content-Type: text/plain; charset=ISO-8859-1
Do any compilers yet support the x->~auto() syntax? Can you link the
proposal that this was a part of?
Thanks
On Tue, Dec 24, 2013 at 10:11 AM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:
> Now that in C++14 we will have
>
> x -> ~auto()
>
> Why not allow that notion when declaring the destructor aswell? And
> why not also for the constructor?
>
> struct A {
> auto() { }
> ~auto() { }
> };
>
>
> Thanks!
>
> --
>
> ---
> 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/.
>
--
---
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/.
--047d7b6783f690699004ee3e0300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Do any compilers yet support the x->~auto() syntax? Can=
you link the proposal that this was a part of?<div><br></div><div>Thanks</=
div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Tue, Dec 24, 2013 at 10:11 AM, Johannes Schaub <span dir=3D"ltr"><<a hre=
f=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johann=
es@googlemail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Now that in C++14 we will have<br>
<br>
=A0 =A0 x -> ~auto()<br>
<br>
Why not allow that notion when declaring the destructor aswell? And<br>
why not also for the constructor?<br>
<br>
=A0 =A0 struct A {<br>
=A0 =A0 =A0 =A0 auto() { }<br>
=A0 =A0 =A0 =A0 ~auto() { }<br>
=A0 =A0 };<br>
<br>
<br>
Thanks!<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7b6783f690699004ee3e0300--
.
Author: =?ISO-8859-1?Q?David_Rodr=EDguez_Ibeas?= <dibeas@ieee.org>
Date: Mon, 30 Dec 2013 13:21:41 -0500
Raw View
--047d7b6d8636f5c6c304eec48346
Content-Type: text/plain; charset=ISO-8859-1
I don't have any strong opinion, but I don't see any value either. In the
case of 'x->~auto();' I can imagine this being inside some generic piece of
code where the actual type might or might not be easy to detect, but in the
case of the declaration of either the constructor or destructor, the name
of the type being defined is just there to use.
How would support for 'auto' when declaring the constructor/destructor help?
On Mon, Dec 23, 2013 at 7:11 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:
> Now that in C++14 we will have
>
> x -> ~auto()
>
> Why not allow that notion when declaring the destructor aswell? And
> why not also for the constructor?
>
> struct A {
> auto() { }
> ~auto() { }
> };
>
>
> Thanks!
>
> --
>
> ---
> 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/.
>
--
---
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/.
--047d7b6d8636f5c6c304eec48346
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I don't have any strong opinion, but I don't see a=
ny value either. In the case of 'x->~auto();' I can imagine this=
being inside some generic piece of code where the actual type might or mig=
ht not be easy to detect, but in the case of the declaration of either the =
constructor or destructor, the name of the type being defined is just there=
to use.<br>
<br>How would support for 'auto' when declaring the constructor/des=
tructor help?</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_q=
uote">On Mon, Dec 23, 2013 at 7:11 PM, Johannes Schaub <span dir=3D"ltr">&l=
t;<a href=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schau=
b.johannes@googlemail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Now that in C++14 we will have<br>
<br>
=A0 =A0 x -> ~auto()<br>
<br>
Why not allow that notion when declaring the destructor aswell? And<br>
why not also for the constructor?<br>
<br>
=A0 =A0 struct A {<br>
=A0 =A0 =A0 =A0 auto() { }<br>
=A0 =A0 =A0 =A0 ~auto() { }<br>
=A0 =A0 };<br>
<br>
<br>
Thanks!<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7b6d8636f5c6c304eec48346--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Wed, 1 Jan 2014 16:09:08 -0800 (PST)
Raw View
------=_Part_7818_655848.1388621348518
Content-Type: text/plain; charset=ISO-8859-1
On Monday, December 23, 2013 4:30:38 PM UTC-8, David Krauss wrote:
>
> Because it looks like nonsense. It would be more expressive to allow
> such for decltype(*this), but alas it would be a breaking change because
> that refers to the enclosing class in a local class within a nonstatic
> member function.
>
It would be nice to otherwise provide universal syntax for "the
> enclosing class."
I brought this up some months ago as decltype(class), which someone (maybe
you? I forget) liked a bit less. Having thought on it a good bit, I'm
still in favor of a decltype(class) since its type doesn't change in
different contexts inside the class declaration or member function
definitions like a decltype(*this) would (e.g. on a const function). It's
also more clear as a legal syntax outside of member function bodies while
decltype(*this) implies that decltype(this) or even decltype(&*this) should
be legal or that 'this' is itself valid outside the function.
--
---
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_7818_655848.1388621348518
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, December 23, 2013 4:30:38 PM UTC-8, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Because it looks like =
nonsense. It would be more expressive to allow=20
<br>such for decltype(*this), but alas it would be a breaking change becaus=
e=20
<br>that refers to the enclosing class in a local class within a nonstatic=
=20
<br>member function.
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;"> </blockquote><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-wid=
th: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; p=
adding-left: 1ex;">It would be nice to otherwise provide universal syntax f=
or "the <br>enclosing class." </blockquote><div> </div><div>=
I brought this up some months ago as decltype(class), which someone (maybe =
you? I forget) liked a bit less. Having thought on it a good bi=
t, I'm still in favor of a decltype(class) since its type doesn't change in=
different contexts inside the class declaration or member function definit=
ions like a decltype(*this) would (e.g. on a const function). It's al=
so more clear as a legal syntax outside of member function bodies while dec=
ltype(*this) implies that decltype(this) or even decltype(&*this) shoul=
d be legal or that 'this' is itself valid outside the function.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_7818_655848.1388621348518--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 02 Jan 2014 12:27:09 +0800
Raw View
On 1/2/14 8:09 AM, Sean Middleditch wrote:
> On Monday, December 23, 2013 4:30:38 PM UTC-8, David Krauss wrote:
>> It would be nice to otherwise provide universal syntax for "the
>> enclosing class."
> =20
> I brought this up some months ago as decltype(class), which someone (mayb=
e
> you? I forget) liked a bit less.
Looks like the debate was on July 26, but I wasn't there. The objection=20
raised was that there may be issues with class completeness, but I don't=20
see how, as it's only alternative syntax with no new semantics.
I would suggest the syntax of "class this". Decltype usually gets the=20
type used to declare an object name, even decltype(auto) which refers to=20
the declaration of a named initializer. (Consequently, such a type=20
cannot be incomplete.) On the other hand, "class this" looks like an=20
elaborated type specifier referring to a class, which is exactly how it=20
should behave.
Given the obviousness and timelessness, it would be surprising if this=20
hasn't been proposed already, or even considered in the first place when=20
Stroustrup was adding classes to C. But I can't find anything on the=20
Web, Google Groups, Usenet, StackOverflow, etc. There are a lot of hits=20
for "=85 class. This =85" though.
> Having thought on it a good bit, I'm
> still in favor of a decltype(class) since its type doesn't change in
> different contexts inside the class declaration or member function
> definitions like a decltype(*this) would (e.g. on a const function). It'=
s
> also more clear as a legal syntax outside of member function bodies while
> decltype(*this) implies that decltype(this) or even decltype(&*this) shou=
ld
> be legal or that 'this' is itself valid outside the function.
The problem with decltype(*this) outside a function body is that it is=20
already meaningfully defined when the class is local to a member=20
function of another class. Allowing it in this corner case might have=20
been an oversight in C++11, but it's probably too significant to break.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Thu, 2 Jan 2014 11:30:17 -0800 (PST)
Raw View
------=_Part_9947_26299536.1388691017589
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On Wednesday, January 1, 2014 8:27:09 PM UTC-8, David Krauss wrote:
>
> I would suggest the syntax of "class this". Decltype usually gets the=20
That looks good to me.
The only other suggestion I might have would venture more into some of the=
=20
reflection proposals, but to have something that "looks like" whatever=20
comes out of those discussions. I value consistency pretty highly.
=20
> Given the obviousness and timelessness, it would be surprising if this=20
> hasn't been proposed already, or even considered in the first place when=
=20
> Stroustrup was adding classes to C. But I can't find anything on the=20
> Web, Google Groups, Usenet, StackOverflow, etc. There are a lot of hits=
=20
> for "=85 class. This =85" though.=20
>
I'm not sure it would have come up before. There's actually not a huge=20
number of use cases for it, and very easy work-arounds in (almost) all the=
=20
ones that do exist. Alternate constructor/destructor syntaxes probably=20
were more about using consistent names ('construct' and 'destruct' or=20
something like that) than about trying to genericize the type names in=20
today's syntax.
The problem with decltype(*this) outside a function body is that it is=20
> already meaningfully defined when the class is local to a member=20
> function of another class. Allowing it in this corner case might have=20
Ah, good catch. I hadn't thought of that. That puts the nail in that=20
coffin.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_9947_26299536.1388691017589
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 1, 2014 8:27:09 PM UTC-8, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would suggest the s=
yntax of "class this". Decltype usually gets the </blockquote><div><br></di=
v><div>That looks good to me.</div><div><br></div><div>The only other sugge=
stion I might have would venture more into some of the reflection proposals=
, but to have something that "looks like" whatever comes out of those discu=
ssions. I value consistency pretty highly.</div><div> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">Given the obviousness and timeless=
ness, it would be surprising if this=20
<br>hasn't been proposed already, or even considered in the first place whe=
n=20
<br>Stroustrup was adding classes to C. But I can't find anything on the=20
<br>Web, Google Groups, Usenet, StackOverflow, etc. There are a lot of hits=
=20
<br>for "=85 class. This =85" though.
<br></blockquote><div><br></div><div>I'm not sure it would have come up bef=
ore. There's actually not a huge number of use cases for it, and very=
easy work-arounds in (almost) all the ones that do exist. Alternate =
constructor/destructor syntaxes probably were more about using consistent n=
ames ('construct' and 'destruct' or something like that) than about trying =
to genericize the type names in today's syntax.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">The problem with decltype(*this) outs=
ide a function body is that it is=20
<br>already meaningfully defined when the class is local to a member=20
<br>function of another class. Allowing it in this corner case might have <=
/blockquote><div><br></div><div>Ah, good catch. I hadn't thought of t=
hat. That puts the nail in that coffin.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_9947_26299536.1388691017589--
.
Author: David Krauss <potswa@gmail.com>
Date: Fri, 03 Jan 2014 10:34:55 +0800
Raw View
On 1/3/14 3:30 AM, Sean Middleditch wrote:
> I'm not sure it would have come up before. There's actually not a huge
> number of use cases for it, and very easy work-arounds in (almost) all the
> ones that do exist.
The only use case I know of, macro pseudo-inheritance, is old as rocks
though and was very popular before it was superseded by CRTP. Apple
added a "this class" keyword to GCC for use by internal macros to
support its kernel extension model, which was ported from ObjC to C++
when they adapted NeXTstep to Mac OS X. If memory serves, the extension
was not adopted by GCC mainline, and it was activated by a special
kernel-mode switch. (Which would suggest that the same feature now
exists in Clang.)
> Alternate constructor/destructor syntaxes probably
> were more about using consistent names ('construct' and 'destruct' or
> something like that) than about trying to genericize the type names in
> today's syntax.
Yeah, in the old days many folks actually wrote __ctor() { q_ = 3; }.
Apple was implementing deeper reflection, generating some internal
tables with the stringized class name and such. ObjC supported such already.
--
---
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/.
.
Author: Richard Smith <metafoo@gmail.com>
Date: Tue, 07 Jan 2014 03:20:53 +0000
Raw View
--001a1136bcce2e395e04ef58dd73
Content-Type: text/plain; charset=ISO-8859-1
On Mon Dec 23 2013 at 4:11:25 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:
Now that in C++14 we will have
x -> ~auto()
This is far from certain. This was suggested within CWG discussions as a
resolution to issue 1586, but the idea hasn't even been presented to the
evolution working group yet, let alone reached a committee vote. Even if
all that goes well, it could be deemed as an extension rather than a
bugfix, and thus would not be part of C++14.
Why not allow that notion when declaring the destructor aswell? And
why not also for the constructor?
struct A {
auto() { }
~auto() { }
};
Thanks!
--
---
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/.
--
---
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/.
--001a1136bcce2e395e04ef58dd73
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>On Mon Dec 23 2013 at 4:11:25 PM, Johannes Schaub <<a href=3D"mailt=
o:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johannes@googlem=
ail.com</a>> wrote:</div><blockquote style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
Now that in C++14 we will have<br>
<br>
=A0 =A0 x -> ~auto()<br></blockquote><div><br></div><div>This is far fro=
m certain. This was suggested within CWG discussions as a resolution to iss=
ue 1586, but the idea hasn't even been presented to the evolution worki=
ng group yet, let alone reached a committee vote. Even if all that goes wel=
l, it could be deemed as an extension rather than a bugfix, and thus would =
not be part of C++14.</div>
<div>=A0</div><blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
Why not allow that notion when declaring the destructor aswell? And<br>
why not also for the constructor?<br>
<br>
=A0 =A0 struct A {<br>
=A0 =A0 =A0 =A0 auto() { }<br>
=A0 =A0 =A0 =A0 ~auto() { }<br>
=A0 =A0 };<br>
<br>
<br>
Thanks!<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isoc<u></u>pp.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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>iso<u><=
/u>cpp.org/group/std-<u></u>proposals/</a>.<br>
</blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a1136bcce2e395e04ef58dd73--
.