Topic: unevaluated this


Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Mon, 15 Sep 2014 09:17:17 -0700 (PDT)
Raw View
------=_Part_3123_661167444.1410797837567
Content-Type: text/plain; charset=UTF-8

Another proposal carrying on from work I did earlier. This is a
continuation of the decltype(class) feature I suggested some time back but
with Ville's suggestion taken to heart. It's now a proposal for allowing
`this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a class
definition body or base specifier list as well as a convenient helper
`std::this_t`.

http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html

Thoughts/comments/critiques would be appreciated. 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/.

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

<div dir=3D"ltr">Another proposal carrying on from work I did earlier. This=
 is a continuation of the decltype(class) feature I suggested some time bac=
k but with Ville's suggestion taken to heart. It's now a proposal for allow=
ing `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a c=
lass definition body or base specifier list as well as a convenient helper =
`std::this_t`.<div><br></div><div>http://htmlpreview.github.io/?https://git=
hub.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html<br></di=
v><div><br></div><div>Thoughts/comments/critiques would be appreciated. Tha=
nks!</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_3123_661167444.1410797837567--

.


Author: Myriachan <myriachan@gmail.com>
Date: Mon, 15 Sep 2014 11:32:54 -0700 (PDT)
Raw View
------=_Part_2211_985551478.1410805974216
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 9:17:17 AM UTC-7, Sean Middleditch wrote:
>
> Another proposal carrying on from work I did earlier. This is a
> continuation of the decltype(class) feature I suggested some time back but
> with Ville's suggestion taken to heart. It's now a proposal for allowing
> `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a class
> definition body or base specifier list as well as a convenient helper
> `std::this_t`.
>
>
> http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html
>
> Thoughts/comments/critiques would be appreciated. Thanks!
>

I don't see how std::this_t could be implemented, because there's no way it
could know in which context it's being used.  Other than the amount of
typing, this would work fine if this is allowed throughout class scope in
all unevaluated contexts:

using my_type = std::remove_cv_t<std::remove_reference_t<decltype(*this)>>;

Melissa

--

---
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_2211_985551478.1410805974216
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 15, 2014 9:17:17 AM UTC-7, Sean Middl=
editch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Another proposal carrying on from work I did earlier. This is a continuatio=
n of the decltype(class) feature I suggested some time back but with Ville'=
s suggestion taken to heart. It's now a proposal for allowing `this` in une=
valuated contexts (decltype, sizeof, etc.) anywhere in a class definition b=
ody or base specifier list as well as a convenient helper `std::this_t`.<di=
v><br></div><div><a href=3D"http://htmlpreview.github.io/?https://github.co=
m/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html" target=3D"_b=
lank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fhtmlpreview.github.io%2F%3Fhttps%3A%2F%2Fgithub.com%2Fseanmiddleditch%2FC=
PlusPlus%2Fblob%2Fmaster%2Funevaluated-this.html\46sa\75D\46sntz\0751\46usg=
\75AFQjCNHWiZl9mP9IjHGA6PSACZ7fC-JtIw';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fhtmlpreview.github.io%2F%3Fh=
ttps%3A%2F%2Fgithub.com%2Fseanmiddleditch%2FCPlusPlus%2Fblob%2Fmaster%2Fune=
valuated-this.html\46sa\75D\46sntz\0751\46usg\75AFQjCNHWiZl9mP9IjHGA6PSACZ7=
fC-JtIw';return true;">http://htmlpreview.github.io/?<wbr>https://github.co=
m/<wbr>seanmiddleditch/CPlusPlus/<wbr>blob/master/unevaluated-this.<wbr>htm=
l</a><br></div><div><br></div><div>Thoughts/comments/critiques would be app=
reciated. Thanks!</div></div></blockquote><div><br>I don't see how std::thi=
s_t could be implemented, because there's no way it could know in which con=
text it's being used.&nbsp; Other than the amount of typing, this would wor=
k fine if <span style=3D"font-family: courier new,monospace;">this</span> i=
s allowed throughout class scope in all unevaluated contexts:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> my_type </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">remove_cv_t</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">remove_reference_t</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">decltype</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(*</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">this</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)&gt=
;&gt;;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></div></code></div><br>Melissa<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_2211_985551478.1410805974216--

.


Author: Sean Middleditch <sean@middleditch.us>
Date: Mon, 15 Sep 2014 12:39:16 -0700
Raw View
Yeah, that was one of the open questions. Would using the this_t<>
alternative (delaying the instantiation until the appropriate context)
work?

The this_t idea is just to offer a convenience shorthand. I don't
think it's necessary, and the my_type you present is certainly
acceptable; this isn't something users are expected to use directly
too often.

Thanks!

On Mon, Sep 15, 2014 at 11:32 AM, Myriachan <myriachan@gmail.com> wrote:
> On Monday, September 15, 2014 9:17:17 AM UTC-7, Sean Middleditch wrote:
>>
>> Another proposal carrying on from work I did earlier. This is a
>> continuation of the decltype(class) feature I suggested some time back but
>> with Ville's suggestion taken to heart. It's now a proposal for allowing
>> `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a class
>> definition body or base specifier list as well as a convenient helper
>> `std::this_t`.
>>
>>
>> http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html
>>
>> Thoughts/comments/critiques would be appreciated. Thanks!
>
>
> I don't see how std::this_t could be implemented, because there's no way it
> could know in which context it's being used.  Other than the amount of
> typing, this would work fine if this is allowed throughout class scope in
> all unevaluated contexts:
>
> using my_type = std::remove_cv_t<std::remove_reference_t<decltype(*this)>>;
>
> Melissa
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
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 <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 14:00:08 -0700
Raw View
--001a11339e8883088e050320eb36
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 12:39 PM, Sean Middleditch <sean@middleditch.us>
wrote:

> Yeah, that was one of the open questions. Would using the this_t<>
> alternative (delaying the instantiation until the appropriate context)
> work?
>
> The this_t idea is just to offer a convenience shorthand. I don't
> think it's necessary, and the my_type you present is certainly
> acceptable; this isn't something users are expected to use directly
> too often.
>

The this_t thing doesn't work: 'this' will be interpreted in the context in
which it appears, and in the definition of 'this_t' it appears outside a
class, so is ill-formed.


> Thanks!
>
> On Mon, Sep 15, 2014 at 11:32 AM, Myriachan <myriachan@gmail.com> wrote:
> > On Monday, September 15, 2014 9:17:17 AM UTC-7, Sean Middleditch wrote:
> >>
> >> Another proposal carrying on from work I did earlier. This is a
> >> continuation of the decltype(class) feature I suggested some time back
> but
> >> with Ville's suggestion taken to heart. It's now a proposal for allowing
> >> `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a
> class
> >> definition body or base specifier list as well as a convenient helper
> >> `std::this_t`.
> >>
> >>
> >>
> http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html
> >>
> >> Thoughts/comments/critiques would be appreciated. Thanks!
> >
> >
> > I don't see how std::this_t could be implemented, because there's no way
> it
> > could know in which context it's being used.  Other than the amount of
> > typing, this would work fine if this is allowed throughout class scope in
> > all unevaluated contexts:
> >
> > using my_type =
> std::remove_cv_t<std::remove_reference_t<decltype(*this)>>;
> >
> > Melissa
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe
> .
> > To unsubscribe from this group and all its topics, 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/.
>
>
>
> --
> Sean Middleditch
> http://seanmiddleditch.com
>
> --
>
> ---
> 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/.

--001a11339e8883088e050320eb36
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 M=
on, Sep 15, 2014 at 12:39 PM, Sean Middleditch <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</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">Yeah, that was one of t=
he open questions. Would using the this_t&lt;&gt;<br>
alternative (delaying the instantiation until the appropriate context)<br>
work?<br>
<br>
The this_t idea is just to offer a convenience shorthand. I don&#39;t<br>
think it&#39;s necessary, and the my_type you present is certainly<br>
acceptable; this isn&#39;t something users are expected to use directly<br>
too often.<br></blockquote><div><br></div><div>The this_t thing doesn&#39;t=
 work: &#39;this&#39; will be interpreted in the context in which it appear=
s, and in the definition of &#39;this_t&#39; it appears outside a class, so=
 is ill-formed.</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">
Thanks!<br>
<span class=3D""><br>
On Mon, Sep 15, 2014 at 11:32 AM, Myriachan &lt;<a href=3D"mailto:myriachan=
@gmail.com">myriachan@gmail.com</a>&gt; wrote:<br>
&gt; On Monday, September 15, 2014 9:17:17 AM UTC-7, Sean Middleditch wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; Another proposal carrying on from work I did earlier. This is a<br=
>
&gt;&gt; continuation of the decltype(class) feature I suggested some time =
back but<br>
&gt;&gt; with Ville&#39;s suggestion taken to heart. It&#39;s now a proposa=
l for allowing<br>
&gt;&gt; `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere i=
n a class<br>
&gt;&gt; definition body or base specifier list as well as a convenient hel=
per<br>
&gt;&gt; `std::this_t`.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; <a href=3D"http://htmlpreview.github.io/?https://github.com/seanmi=
ddleditch/CPlusPlus/blob/master/unevaluated-this.html" target=3D"_blank">ht=
tp://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/bl=
ob/master/unevaluated-this.html</a><br>
&gt;&gt;<br>
&gt;&gt; Thoughts/comments/critiques would be appreciated. Thanks!<br>
&gt;<br>
&gt;<br>
&gt; I don&#39;t see how std::this_t could be implemented, because there&#3=
9;s no way it<br>
&gt; could know in which context it&#39;s being used.=C2=A0 Other than the =
amount of<br>
&gt; typing, this would work fine if this is allowed throughout class scope=
 in<br>
&gt; all unevaluated contexts:<br>
&gt;<br>
&gt; using my_type =3D std::remove_cv_t&lt;std::remove_reference_t&lt;declt=
ype(*this)&gt;&gt;;<br>
&gt;<br>
&gt; Melissa<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
</span>&gt; You received this message because you are subscribed to a topic=
 in the<br>
<span class=3D"">&gt; Google Groups &quot;ISO C++ Standard - Future Proposa=
ls&quot; group.<br>
</span>&gt; To unsubscribe from this topic, visit<br>
&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-proposal=
s/pienLjyOVJk/unsubscribe" target=3D"_blank">https://groups.google.com/a/is=
ocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe</a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to<br=
>
<span class=3D"im HOEnZb">&gt; <a href=3D"mailto:std-proposals%2Bunsubscrib=
e@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
<br>
<br>
</span><span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Sean Middleditch<br>
<a href=3D"http://seanmiddleditch.com" target=3D"_blank">http://seanmiddled=
itch.com</a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%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>
</div></div></blockquote></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 />

--001a11339e8883088e050320eb36--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 14:06:18 -0700
Raw View
--001a113403d0955c46050321014b
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 9:17 AM, Sean Middleditch <
sean.middleditch@gmail.com> wrote:

> Another proposal carrying on from work I did earlier. This is a
> continuation of the decltype(class) feature I suggested some time back but
> with Ville's suggestion taken to heart. It's now a proposal for allowing
> `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a class
> definition body or base specifier list as well as a convenient helper
> `std::this_t`.
>
>
> http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html
>
> Thoughts/comments/critiques would be appreciated. Thanks!
>

This seems dangerous to me; it gets cv-qualifiers wrong. Consider:

  struct S {
    decltype(this) f() const;
    auto g() const -> decltype(this);
  };

Note that f() returns S*, and g() returns const S*. The current
restrictions on where 'this' can appear are not related to where we can get
a value for it, they're simply the set of places where it has a meaningful
type.

Your use cases all appear to be 'get the current class type', not 'get the
type of a pointer to the current instance, with missing cv-qualifiers in
some cases', so I don't see that 'this' is the right thing to be going
after. Given that your std::this_t doesn't work, what's wrong with
decltype(this)?

--

---
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/.

--001a113403d0955c46050321014b
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 M=
on, Sep 15, 2014 at 9:17 AM, Sean Middleditch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.middleditch@g=
mail.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"><div dir=
=3D"ltr">Another proposal carrying on from work I did earlier. This is a co=
ntinuation of the decltype(class) feature I suggested some time back but wi=
th Ville&#39;s suggestion taken to heart. It&#39;s now a proposal for allow=
ing `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a c=
lass definition body or base specifier list as well as a convenient helper =
`std::this_t`.<div><br></div><div><a href=3D"http://htmlpreview.github.io/?=
https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.h=
tml" target=3D"_blank">http://htmlpreview.github.io/?https://github.com/sea=
nmiddleditch/CPlusPlus/blob/master/unevaluated-this.html</a><br></div><div>=
<br></div><div>Thoughts/comments/critiques would be appreciated. Thanks!</d=
iv></div></blockquote><div><br></div><div>This seems dangerous to me; it ge=
ts cv-qualifiers wrong. Consider:</div><div><br></div><div>=C2=A0 struct S =
{</div><div>=C2=A0 =C2=A0 decltype(this) f() const;</div><div>=C2=A0 =C2=A0=
 auto g() const -&gt; decltype(this);</div><div>=C2=A0 };</div><div><br></d=
iv><div>Note that f() returns S*, and g() returns const S*. The current res=
trictions on where &#39;this&#39; can appear are not related to where we ca=
n get a value for it, they&#39;re simply the set of places where it has a m=
eaningful type.</div><div><br></div><div>Your use cases all appear to be &#=
39;get the current class type&#39;, not &#39;get the type of a pointer to t=
he current instance, with missing cv-qualifiers in some cases&#39;, so I do=
n&#39;t see that &#39;this&#39; is the right thing to be going after. Given=
 that your std::this_t doesn&#39;t work, what&#39;s wrong with decltype(thi=
s)?</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 />

--001a113403d0955c46050321014b--

.


Author: Sean Middleditch <sean@middleditch.us>
Date: Mon, 15 Sep 2014 14:10:30 -0700
Raw View
That makes a lot of sense. I'll remove it and just focus on the
unevaluated this part. Thanks!

On Mon, Sep 15, 2014 at 2:00 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> On Mon, Sep 15, 2014 at 12:39 PM, Sean Middleditch <sean@middleditch.us>
> wrote:
>>
>> Yeah, that was one of the open questions. Would using the this_t<>
>> alternative (delaying the instantiation until the appropriate context)
>> work?
>>
>> The this_t idea is just to offer a convenience shorthand. I don't
>> think it's necessary, and the my_type you present is certainly
>> acceptable; this isn't something users are expected to use directly
>> too often.
>
>
> The this_t thing doesn't work: 'this' will be interpreted in the context in
> which it appears, and in the definition of 'this_t' it appears outside a
> class, so is ill-formed.
>
>>
>> Thanks!
>>
>> On Mon, Sep 15, 2014 at 11:32 AM, Myriachan <myriachan@gmail.com> wrote:
>> > On Monday, September 15, 2014 9:17:17 AM UTC-7, Sean Middleditch wrote:
>> >>
>> >> Another proposal carrying on from work I did earlier. This is a
>> >> continuation of the decltype(class) feature I suggested some time back
>> >> but
>> >> with Ville's suggestion taken to heart. It's now a proposal for
>> >> allowing
>> >> `this` in unevaluated contexts (decltype, sizeof, etc.) anywhere in a
>> >> class
>> >> definition body or base specifier list as well as a convenient helper
>> >> `std::this_t`.
>> >>
>> >>
>> >>
>> >> http://htmlpreview.github.io/?https://github.com/seanmiddleditch/CPlusPlus/blob/master/unevaluated-this.html
>> >>
>> >> Thoughts/comments/critiques would be appreciated. Thanks!
>> >
>> >
>> > I don't see how std::this_t could be implemented, because there's no way
>> > it
>> > could know in which context it's being used.  Other than the amount of
>> > typing, this would work fine if this is allowed throughout class scope
>> > in
>> > all unevaluated contexts:
>> >
>> > using my_type =
>> > std::remove_cv_t<std::remove_reference_t<decltype(*this)>>;
>> >
>> > Melissa
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit
>> >
>> > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe.
>> > To unsubscribe from this group and all its topics, 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/.
>>
>>
>>
>> --
>> Sean Middleditch
>> http://seanmiddleditch.com
>>
>> --
>>
>> ---
>> 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 a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
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: Zhihao Yuan <zy@miator.net>
Date: Mon, 15 Sep 2014 17:12:35 -0400
Raw View
--001a1136b2b60f272505032118bc
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 5:06 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

>
> Given that your std::this_t doesn't work, what's wrong with decltype(this)?
>

The name.  Well, this_t is not the right name too, but we can bike-shed it,
but decltype(this) strongly suggests it gives type of `this`, which is a
pointer,
while the paper suggests it to be the type of the implied object, which is
more convenient from my point of view.

--
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/.

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

<div dir=3D"ltr">On Mon, Sep 15, 2014 at 5:06 PM, Richard Smith <span dir=
=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ric=
hard@metafoo.co.uk</a>&gt;</span> wrote:<br><div class=3D"gmail_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"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">Given that your std::=
this_t doesn&#39;t work, what&#39;s wrong with decltype(this)?</div></div><=
/div></blockquote></div><br></div><div class=3D"gmail_extra">The name.=C2=
=A0 Well, this_t is not the right name too, but we can bike-shed it,<br></d=
iv><div class=3D"gmail_extra">but decltype(this) strongly suggests it gives=
 type of `this`, which is a pointer,<br></div><div class=3D"gmail_extra">wh=
ile the paper suggests it to be the type of the implied object, which is<br=
>more convenient from my point of view.<br clear=3D"all"></div><div class=
=3D"gmail_extra"><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to pred=
ict 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 />

--001a1136b2b60f272505032118bc--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 14:24:40 -0700
Raw View
--047d7b3a7e303fb5920503214314
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 2:12 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Mon, Sep 15, 2014 at 5:06 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>
>>
>> Given that your std::this_t doesn't work, what's wrong with
>> decltype(this)?
>>
>
> The name.  Well, this_t is not the right name too, but we can bike-shed it,
> but decltype(this) strongly suggests it gives type of `this`, which is a
> pointer,
> while the paper suggests it to be the type of the implied object, which is
> more convenient from my point of view.
>

Oops, sorry, I meant to refer to the previous proposal of
'decltype(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/.

--047d7b3a7e303fb5920503214314
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 M=
on, Sep 15, 2014 at 2:12 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</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"><div dir=3D"ltr"><span class=3D"">On Mon,=
 Sep 15, 2014 at 5:06 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&gt;=
</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><br=
><div class=3D"gmail_quote">Given that your std::this_t doesn&#39;t work, w=
hat&#39;s wrong with decltype(this)?</div></div></div></blockquote></div><b=
r></div></span><div class=3D"gmail_extra">The name.=C2=A0 Well, this_t is n=
ot the right name too, but we can bike-shed it,<br></div><div class=3D"gmai=
l_extra">but decltype(this) strongly suggests it gives type of `this`, whic=
h is a pointer,<br></div><div class=3D"gmail_extra">while the paper suggest=
s it to be the type of the implied object, which is<br>more convenient from=
 my point of view.</div></div></blockquote><div><br></div><div>Oops, sorry,=
 I meant to refer to the previous proposal of &#39;decltype(class)&#39;. =
=3D)=C2=A0</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 />

--047d7b3a7e303fb5920503214314--

.


Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 15 Sep 2014 18:09:29 -0400
Raw View
--001a11338eee818d15050321e398
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 5:24 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

>
> Oops, sorry, I meant to refer to the previous proposal of
> 'decltype(class)'. =)
>

Err, I misparsed the paper, too.

Copy-pasting Ville's comment on decltype(class):

  "The use of the type and value category of 'this' is already allowed in
static member
functions as per [expr.prim.general]/3. Allowing similar uses in the class
definition
has its problems, but decltype(class) likely doesn't solve those problems
(the type may
be incomplete because the class definition is not yet known sufficiently,
all
sorts of chicken-and-egg problems arise). "

// and he referred you to provide more details about type completeness here

--
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/.

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

<div dir=3D"ltr">On Mon, Sep 15, 2014 at 5:24 PM, Richard Smith <span dir=
=3D"ltr">&lt;<a href=3D"mailto:richard@metafoo.co.uk" target=3D"_blank">ric=
hard@metafoo.co.uk</a>&gt;</span> wrote:<br><div class=3D"gmail_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"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span></span><div>Oop=
s, sorry, I meant to refer to the previous proposal of &#39;decltype(class)=
&#39;. =3D)=C2=A0</div></div></div></div></blockquote></div><br></div><div =
class=3D"gmail_extra">Err, I misparsed the paper, too.<br><br></div><div cl=
ass=3D"gmail_extra">Copy-pasting Ville&#39;s comment on decltype(class):<br=
><br>=C2=A0 &quot;The use of the type and value category of &#39;this&#39; =
is already allowed in static member<br>functions as per [expr.prim.general]=
/3. Allowing similar uses in the class definition<br>has its problems, but =
decltype(class) likely doesn&#39;t solve those problems (the type may<br>be=
 incomplete because the class definition is not yet known sufficiently, all=
<br>sorts of chicken-and-egg problems arise). &quot;<br><br></div><div clas=
s=3D"gmail_extra">// and he referred you to provide more details about type=
 completeness here<br></div><div class=3D"gmail_extra"><br>-- <br>Zhihao Yu=
an, ID lichray<br>The best way to predict the future is to invent it.<br>__=
_________________________________________________<br>4BSD -- <a href=3D"htt=
p://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 />

--001a11338eee818d15050321e398--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 15:43:11 -0700
Raw View
--001a1133375c11cb350503225c92
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 3:09 PM, Zhihao Yuan <zy@miator.net> wrote:

> On Mon, Sep 15, 2014 at 5:24 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
>
>>
>> Oops, sorry, I meant to refer to the previous proposal of
>> 'decltype(class)'. =)
>>
>
> Err, I misparsed the paper, too.
>
> Copy-pasting Ville's comment on decltype(class):
>
>   "The use of the type and value category of 'this' is already allowed in
> static member
> functions as per [expr.prim.general]/3.
>

This is only permitted as a hack: compilers don't know for sure whether
they have an out-of-line definition of a static or non-static member
function until they get to the end of the function declarator. 'this' is
permitted before then. To support this, the type and value category of
'this' are defined for a static member function, but your program is
ill-formed if it actually uses 'this' in a static member function.

Example:

struct S {
  template<typename T> auto f() -> S*;
  template<typename T> static auto f() -> const S*;
};
template<typename T> auto S::f() -> decltype(this) {}

Here, we cannot tell whether the out-of-line definition is static or not
unless we know the type of 'this'. So we define that 'this' has type 'S*'
for a static member function, and we're able to resolve the redefinition to
being the non-static function, and all is OK.

Allowing similar uses in the class definition
> has its problems, but decltype(class) likely doesn't solve those problems
> (the type may
> be incomplete because the class definition is not yet known sufficiently,
> all
> sorts of chicken-and-egg problems arise). "
>
> // and he referred you to provide more details about type completeness here
>

Class completeness should not be a problem here any more than it would be
if you named the class by its name; I don't anticipate any new problems in
that direction, but we would have a new syntax for writing the existing
problems. (I'd expect decltype(class) to be identical to naming the class
in almost all ways -- except where the class is anonymous, or its name is
hidden, or a typedef-name is disallowed etc.)

--

---
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/.

--001a1133375c11cb350503225c92
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 M=
on, Sep 15, 2014 at 3:09 PM, Zhihao Yuan <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Mon, Sep 15, 2014 =
at 5:24 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D"mailto:richard@m=
etafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&gt;</span> wrote:=
<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
<span></span><div>Oops, sorry, I meant to refer to the previous proposal of=
 &#39;decltype(class)&#39;. =3D)=C2=A0</div></div></div></div></blockquote>=
</div><br></div></span><div class=3D"gmail_extra">Err, I misparsed the pape=
r, too.<br><br></div><div class=3D"gmail_extra">Copy-pasting Ville&#39;s co=
mment on decltype(class):<br><br>=C2=A0 &quot;The use of the type and value=
 category of &#39;this&#39; is already allowed in static member<br>function=
s as per [expr.prim.general]/3.</div></div></blockquote><div><br></div><div=
>This is only permitted as a hack: compilers don&#39;t know for sure whethe=
r they have an out-of-line definition of a static or non-static member func=
tion until they get to the end of the function declarator. &#39;this&#39; i=
s permitted before then. To support this, the type and value category of &#=
39;this&#39; are defined for a static member function, but your program is =
ill-formed if it actually uses &#39;this&#39; in a static member function.<=
/div><div><br></div><div>Example:</div><div><br></div><div><div>struct S {<=
/div><div>=C2=A0 template&lt;typename T&gt; auto f() -&gt; S*; =C2=A0 =C2=
=A0 =C2=A0</div><div>=C2=A0 template&lt;typename T&gt; static auto f() -&gt=
; const S*;</div><div>};</div><div>template&lt;typename T&gt; auto S::f() -=
&gt; decltype(this) {}</div></div><div><br></div><div>Here, we cannot tell =
whether the out-of-line definition is static or not unless we know the type=
 of &#39;this&#39;. So we define that &#39;this&#39; has type &#39;S*&#39; =
for a static member function, and we&#39;re able to resolve the redefinitio=
n to being the non-static function, and all is OK.<br></div><div><br></div>=
<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;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">Allowing simil=
ar uses in the class definition<br>has its problems, but decltype(class) li=
kely doesn&#39;t solve those problems (the type may<br>be incomplete becaus=
e the class definition is not yet known sufficiently, all<br>sorts of chick=
en-and-egg problems arise). &quot;<br><br></div><div class=3D"gmail_extra">=
// and he referred you to provide more details about type completeness here=
</div></div></blockquote><div><br></div><div>Class completeness should not =
be a problem here any more than it would be if you named the class by its n=
ame; I don&#39;t anticipate any new problems in that direction, but we woul=
d have a new syntax for writing the existing problems. (I&#39;d expect decl=
type(class) to be identical to naming the class in almost all ways -- excep=
t where the class is anonymous, or its name is hidden, or a typedef-name is=
 disallowed etc.)</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 />

--001a1133375c11cb350503225c92--

.


Author: Sean Middleditch <sean@middleditch.us>
Date: Mon, 15 Sep 2014 15:50:25 -0700
Raw View
On Mon, Sep 15, 2014 at 2:06 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> after. Given that your std::this_t doesn't work, what's wrong with
> decltype(this)?

decltype(class) ?

Other than that I was under the impression that at least some of the
committee already hated it... nothing. I still prefer decltype(class)
[maybe spelt some other way; thisdecl or whatever floats the
committee's boat] for pretty much most of the reasons you and others
have listed this time around. :)
--
Sean Middleditch
http://seanmiddleditch.com

--

---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 15 Sep 2014 15:54:11 -0700 (PDT)
Raw View
------=_Part_2851_302219685.1410821651491
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 7:43:13 PM UTC-3, Richard Smith wrote:
>
>
> Class completeness should not be a problem here any more than it would be
> if you named the class by its name; I don't anticipate any new problems in
> that direction, but we would have a new syntax for writing the existing
> problems. (I'd expect decltype(class) to be identical to naming the class
> in almost all ways -- except where the class is anonymous, or its name is
> hidden, or a typedef-name is disallowed etc.)
>

So, using decltype(class) would you be able to name/declare a constructor
for an anonymous 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/.

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

<div dir=3D"ltr">On Monday, September 15, 2014 7:43:13 PM UTC-3, Richard Sm=
ith 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"><di=
v><div class=3D"gmail_quote"><br><div>Class completeness should not be a pr=
oblem here any more than it would be if you named the class by its name; I =
don't anticipate any new problems in that direction, but we would have a ne=
w syntax for writing the existing problems. (I'd expect decltype(class) to =
be identical to naming the class in almost all ways -- except where the cla=
ss is anonymous, or its name is hidden, or a typedef-name is disallowed etc=
..)</div></div></div></div></blockquote><div><br>So, using decltype(class) w=
ould you be able to name/declare a constructor for an anonymous class?<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_2851_302219685.1410821651491--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 15 Sep 2014 17:01:04 -0700
Raw View
--047d7b3a7daa8da68905032372bf
Content-Type: text/plain; charset=UTF-8

On Mon, Sep 15, 2014 at 3:54 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:

> On Monday, September 15, 2014 7:43:13 PM UTC-3, Richard Smith wrote:
>>
>>
>> Class completeness should not be a problem here any more than it would be
>> if you named the class by its name; I don't anticipate any new problems in
>> that direction, but we would have a new syntax for writing the existing
>> problems. (I'd expect decltype(class) to be identical to naming the class
>> in almost all ways -- except where the class is anonymous, or its name is
>> hidden, or a typedef-name is disallowed etc.)
>>
>
> So, using decltype(class) would you be able to name/declare a constructor
> for an anonymous class?
>

Class names are one of the places where *typedef-name*s are disallowed, so
I would not expect that to work. For member anonymous unions in particular,
it's important that we continue to disallow constructors, since some of the
language rules rely on there not being any.

--

---
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/.

--047d7b3a7daa8da68905032372bf
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 M=
on, Sep 15, 2014 at 3:54 PM, Matheus Izvekov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mizvekov@gmail.com" target=3D"_blank">mizvekov@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"><div dir=3D"ltr"><span cla=
ss=3D"">On Monday, September 15, 2014 7:43:13 PM UTC-3, Richard Smith 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"><div><div class=
=3D"gmail_quote"><br><div>Class completeness should not be a problem here a=
ny more than it would be if you named the class by its name; I don&#39;t an=
ticipate any new problems in that direction, but we would have a new syntax=
 for writing the existing problems. (I&#39;d expect decltype(class) to be i=
dentical to naming the class in almost all ways -- except where the class i=
s anonymous, or its name is hidden, or a typedef-name is disallowed etc.)</=
div></div></div></div></blockquote></span><div><br>So, using decltype(class=
) would you be able to name/declare a constructor for an anonymous class?</=
div></div></blockquote><div><br></div><div>Class names are one of the place=
s where <i>typedef-name</i>s are disallowed, so I would not expect that to =
work. For member anonymous unions in particular, it&#39;s important that we=
 continue to disallow constructors, since some of the language rules rely o=
n there not being any.</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 />

--047d7b3a7daa8da68905032372bf--

.


Author: Thiago Macieira <thiago@macieira.org>
Date: Mon, 15 Sep 2014 17:02:41 -0700
Raw View
On Monday 15 September 2014 15:54:11 Matheus Izvekov wrote:
> On Monday, September 15, 2014 7:43:13 PM UTC-3, Richard Smith wrote:
> > Class completeness should not be a problem here any more than it would be
> > if you named the class by its name; I don't anticipate any new problems in
> > that direction, but we would have a new syntax for writing the existing
> > problems. (I'd expect decltype(class) to be identical to naming the class
> > in almost all ways -- except where the class is anonymous, or its name is
> > hidden, or a typedef-name is disallowed etc.)
>
> So, using decltype(class) would you be able to name/declare a constructor
> for an anonymous class?

It doesn't have to be allowed in that position. decltype is a type, the fact
that the identifier for a constructor or destructor is the same can be
considered a coincidence.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 15 Sep 2014 17:49:38 -0700 (PDT)
Raw View
------=_Part_2903_1262420846.1410828578449
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 9:30:35 PM UTC-3, Thiago Macieira wrote:
>
> It doesn't have to be allowed in that position. decltype is a type, the
> fact
> that the identifier for a constructor or destructor is the same can be
> considered a coincidence.
>
>
Right. I was just wondering if that proposal would also tackle the problem
of naming the constructors/destructors of anonymous classes/unions.

--

---
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_2903_1262420846.1410828578449
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 15, 2014 9:30:35 PM UTC-3, Thiago Mac=
ieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It doesn't have to=
 be allowed in that position. decltype is a type, the fact=20
<br>that the identifier for a constructor or destructor is the same can be=
=20
<br>considered a coincidence.
<br>
<br></blockquote><div><br>Right. I was just wondering if that proposal woul=
d also tackle the problem of naming the constructors/destructors of anonymo=
us classes/unions.<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_2903_1262420846.1410828578449--

.


Author: Myriachan <myriachan@gmail.com>
Date: Mon, 15 Sep 2014 19:10:26 -0700 (PDT)
Raw View
------=_Part_1030_336721589.1410833426271
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 5:49:38 PM UTC-7, Matheus Izvekov wrote:
>
> On Monday, September 15, 2014 9:30:35 PM UTC-3, Thiago Macieira wrote:
>>
>> It doesn't have to be allowed in that position. decltype is a type, the
>> fact
>> that the identifier for a constructor or destructor is the same can be
>> considered a coincidence.
>>
>>
> Right. I was just wondering if that proposal would also tackle the problem
> of naming the constructors/destructors of anonymous classes/unions.
>

Current C++ doesn't allow typedefs to be used as constructor names, anyway:

struct Kitty
{
    typedef Kitty KittyType;
    static_assert(std::is_same<Kitty, KittyType>::value, "not the same");

    KittyType(int x) // ill-formed; must be Kitty
    :   m_x(x)
    {
    }

    int m_x;
};


Melissa

--

---
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_1030_336721589.1410833426271
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 15, 2014 5:49:38 PM UTC-7, Matheus Iz=
vekov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Monday, September 15, 2014 9:30:35 PM UTC-3, Thiago Macieira wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">It doesn't have to be allowed in that pos=
ition. decltype is a type, the fact=20
<br>that the identifier for a constructor or destructor is the same can be=
=20
<br>considered a coincidence.
<br>
<br></blockquote><div><br>Right. I was just wondering if that proposal woul=
d also tackle the problem of naming the constructors/destructors of anonymo=
us classes/unions.<br></div></div></blockquote><div><br>Current C++ doesn't=
 allow <span style=3D"font-family: courier new,monospace;">typedef</span>s =
to be used as constructor names, anyway:<br><br><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border-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><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Kitty</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">typedef</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Kitty</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">KittyType</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">static_assert</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">is_same</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Kitty</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">KittyType</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">value</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #080;" class=3D"styled-by-prettify">"not the same"</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">KittyType=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// ill-formed; must be Kitty</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> &nbsp; m_x</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
0;" 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"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>&nbsp; &nbsp; <br>&nbsp; &nbsp; </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> m_x</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span></div></code></div><br><br>Melissa<br><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_1030_336721589.1410833426271--

.


Author: Matheus Izvekov <mizvekov@gmail.com>
Date: Mon, 15 Sep 2014 19:20:42 -0700 (PDT)
Raw View
------=_Part_3164_145032213.1410834042257
Content-Type: text/plain; charset=UTF-8

On Monday, September 15, 2014 11:10:26 PM UTC-3, Myriachan wrote:
>
>
> Current C++ doesn't allow typedefs to be used as constructor names,
> anyway:
>

Right, but it might be possible to special case decltype(class) just for
this :)

--

---
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_3164_145032213.1410834042257
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, September 15, 2014 11:10:26 PM UTC-3, Myriachan=
 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"><br><d=
iv>Current C++ doesn't allow <span style=3D"font-family:courier new,monospa=
ce">typedef</span>s to be used as constructor names, anyway:<br></div></div=
></blockquote><div><br>Right, but it might be possible to special case decl=
type(class) just for this :)<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_3164_145032213.1410834042257--

.


Author: Sean Middleditch <sean@middleditch.us>
Date: Mon, 15 Sep 2014 20:51:40 -0700
Raw View
So the consensus I'm getting out of this is that I should abandon
unevaluated this and return to the decltype(class) idea and write an
actual paper about that instead. Anyone think that's a bad idea and I
should stay the current course?

/If/ I did that, it would be the simplest version of decltype(class)
possible. It's just a type alias for the current class (or a template
alias if the current class is a class template). It's usable anywhere
in the class definition, member definitions, or base specifier list.
It would not enable you to do anything a type alias cannot otherwise
do. Additional uses of the syntax could be added by a future paper if
someone comes up with a good use case.

On Mon, Sep 15, 2014 at 7:20 PM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Monday, September 15, 2014 11:10:26 PM UTC-3, Myriachan wrote:
>>
>>
>> Current C++ doesn't allow typedefs to be used as constructor names,
>> anyway:
>
>
> Right, but it might be possible to special case decltype(class) just for
> this :)
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
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: Matheus Izvekov <mizvekov@gmail.com>
Date: Tue, 16 Sep 2014 04:51:24 -0700 (PDT)
Raw View
------=_Part_348_97213119.1410868284586
Content-Type: text/plain; charset=UTF-8

On Tuesday, September 16, 2014 12:51:41 AM UTC-3, Sean Middleditch wrote:
>
> So the consensus I'm getting out of this is that I should abandon
> unevaluated this and return to the decltype(class) idea and write an
> actual paper about that instead. Anyone think that's a bad idea and I
> should stay the current course?
>
>
Would it be too hard for this to get accepted if it introduced another
keyword?
If it wouldn't, how about a new keyword that acts like an alias for the
name of the current class?
It could be used both for specifying a type, and naming constructors /
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/.

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

<div dir=3D"ltr">On Tuesday, September 16, 2014 12:51:41 AM UTC-3, Sean Mid=
dleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">So the consensu=
s I'm getting out of this is that I should abandon
<br>unevaluated this and return to the decltype(class) idea and write an
<br>actual paper about that instead. Anyone think that's a bad idea and I
<br>should stay the current course?
<br>
<br></blockquote><div><br>Would it be too hard for this to get accepted if =
it introduced another keyword?<br>If it wouldn't, how about a new keyword t=
hat acts like an alias for the name of the current class?<br>It could be us=
ed both for specifying a type, and naming constructors / destructors. :)<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_348_97213119.1410868284586--

.


Author: Sean Middleditch <sean@middleditch.us>
Date: Tue, 16 Sep 2014 09:26:12 -0700
Raw View
I would offer some alternative spellings in a paper. I'd leave off the
ability to name the constructor/destructor for now, though I would
leave a note in the paper that it's a possible extension point and let
the committee decide if they want a new paper or a second version of
this paper that adds that feature. I'd prefer to keep things tightly
specified but easily extended. But that's me.

On Tue, Sep 16, 2014 at 4:51 AM, Matheus Izvekov <mizvekov@gmail.com> wrote:
> On Tuesday, September 16, 2014 12:51:41 AM UTC-3, Sean Middleditch wrote:
>>
>> So the consensus I'm getting out of this is that I should abandon
>> unevaluated this and return to the decltype(class) idea and write an
>> actual paper about that instead. Anyone think that's a bad idea and I
>> should stay the current course?
>>
>
> Would it be too hard for this to get accepted if it introduced another
> keyword?
> If it wouldn't, how about a new keyword that acts like an alias for the name
> of the current class?
> It could be used both for specifying a type, and naming constructors /
> destructors. :)
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/.



--
Sean Middleditch
http://seanmiddleditch.com

--

---
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: Corentin <corentin.jabot@gmail.com>
Date: Thu, 26 Oct 2017 01:54:10 -0700 (PDT)
Raw View
------=_Part_148_1552926257.1509008050570
Content-Type: multipart/alternative;
 boundary="----=_Part_149_1038126268.1509008050571"

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

I'm interested in this feature, what's the current status ?

Le mardi 16 septembre 2014 18:26:16 UTC+2, Sean Middleditch a =C3=A9crit :
>
> I would offer some alternative spellings in a paper. I'd leave off the=20
> ability to name the constructor/destructor for now, though I would=20
> leave a note in the paper that it's a possible extension point and let=20
> the committee decide if they want a new paper or a second version of=20
> this paper that adds that feature. I'd prefer to keep things tightly=20
> specified but easily extended. But that's me.=20
>
> On Tue, Sep 16, 2014 at 4:51 AM, Matheus Izvekov <mizv...@gmail.com=20
> <javascript:>> wrote:=20
> > On Tuesday, September 16, 2014 12:51:41 AM UTC-3, Sean Middleditch=20
> wrote:=20
> >>=20
> >> So the consensus I'm getting out of this is that I should abandon=20
> >> unevaluated this and return to the decltype(class) idea and write an=
=20
> >> actual paper about that instead. Anyone think that's a bad idea and I=
=20
> >> should stay the current course?=20
> >>=20
> >=20
> > Would it be too hard for this to get accepted if it introduced another=
=20
> > keyword?=20
> > If it wouldn't, how about a new keyword that acts like an alias for the=
=20
> name=20
> > of the current class?=20
> > It could be used both for specifying a type, and naming constructors /=
=20
> > destructors. :)=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to a topic in the=
=20
> > Google Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this topic, visit=20
> >=20
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOVJk/=
unsubscribe.=20
>
> > To unsubscribe from this group and all its topics, send an email to=20
> > std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>
>
>
> --=20
> Sean Middleditch=20
> http://seanmiddleditch.com=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2bbfe507-8c8c-42e1-ab7a-647b0e636e0c%40isocpp.or=
g.

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

<div dir=3D"ltr">I&#39;m interested in this feature, what&#39;s the current=
 status ?<br><br>Le mardi 16 septembre 2014 18:26:16 UTC+2, Sean Middleditc=
h a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I would o=
ffer some alternative spellings in a paper. I&#39;d leave off the
<br>ability to name the constructor/destructor for now, though I would
<br>leave a note in the paper that it&#39;s a possible extension point and =
let
<br>the committee decide if they want a new paper or a second version of
<br>this paper that adds that feature. I&#39;d prefer to keep things tightl=
y
<br>specified but easily extended. But that&#39;s me.
<br>
<br>On Tue, Sep 16, 2014 at 4:51 AM, Matheus Izvekov &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"hD6E81NBeyEJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">mizv...@gmail.com</a>&g=
t; wrote:
<br>&gt; On Tuesday, September 16, 2014 12:51:41 AM UTC-3, Sean Middleditch=
 wrote:
<br>&gt;&gt;
<br>&gt;&gt; So the consensus I&#39;m getting out of this is that I should =
abandon
<br>&gt;&gt; unevaluated this and return to the decltype(class) idea and wr=
ite an
<br>&gt;&gt; actual paper about that instead. Anyone think that&#39;s a bad=
 idea and I
<br>&gt;&gt; should stay the current course?
<br>&gt;&gt;
<br>&gt;
<br>&gt; Would it be too hard for this to get accepted if it introduced ano=
ther
<br>&gt; keyword?
<br>&gt; If it wouldn&#39;t, how about a new keyword that acts like an alia=
s for the name
<br>&gt; of the current class?
<br>&gt; It could be used both for specifying a type, and naming constructo=
rs /
<br>&gt; destructors. :)
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to a topic in=
 the
<br>&gt; Google Groups &quot;ISO C++ Standard - Future Proposals&quot; grou=
p.
<br>&gt; To unsubscribe from this topic, visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/pienLjyOVJk/unsubscribe" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/topic/std-p=
roposals/pienLjyOVJk/unsubscribe&#39;;return true;" onclick=3D"this.href=3D=
&#39;https://groups.google.com/a/isocpp.org/d/topic/std-proposals/pienLjyOV=
Jk/unsubscribe&#39;;return true;">https://groups.google.com/a/<wbr>isocpp.o=
rg/d/topic/std-<wbr>proposals/pienLjyOVJk/<wbr>unsubscribe</a>.
<br>&gt; To unsubscribe from this group and all its topics, send an email t=
o
<br>&gt; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"hD6E81NBeyEJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"hD6E81NBeyEJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;htt=
p://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;return true;" =
onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.org/group/std=
-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>isocpp.org/g=
roup/std-<wbr>proposals/</a>.
<br>
<br>
<br>
<br>--=20
<br>Sean Middleditch
<br><a href=3D"http://seanmiddleditch.com" target=3D"_blank" rel=3D"nofollo=
w" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2=
F%2Fseanmiddleditch.com\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHx3WLavT-kb=
ToOv7IL4uvcN5l-vg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www=
..google.com/url?q\x3dhttp%3A%2F%2Fseanmiddleditch.com\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNHx3WLavT-kbToOv7IL4uvcN5l-vg&#39;;return true;">http://s=
eanmiddleditch.com</a>
<br></blockquote></div>

<p></p>

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

------=_Part_149_1038126268.1509008050571--

------=_Part_148_1552926257.1509008050570--

.