------=_Part_2959_3889959.1374775230926
Content-Type: text/plain; charset=ISO-8859-1

A good currently-missing feature, which I'm unsure whether or not should
fall under the reflection banner, would be the ability to look up the type
of the current class definition.

An example of some common code, which can be a small burden:

   class foo {
     MACRO(foo); // duplicating class name, error-prone, plays very poorly
with refactoring tools
   };

   class bar {
     typedef bar my_type;  // wordy duplication even for short-named
example; still error-prone
   }

Having to duplicate the class name inside the class's own definition can be
ever so slightly error-prone.  I'd like to think that most of those macro
uses will just go away once compile-time reflection is in, but since said
reflection has not been proposed at all that I can tell, that's just a
hopeful guess.

The idea is to offer a simple construct decltype(class).  This is the type
of the current class definition.  If inside a method, it is equal to the
type of the class containing the method (very similar to decltype(*this)
but not quite the same).  The most important difference from
decltype(*this) imo is the ability to use it outside of a method definition
body, e.g. in return types.

decltype(class) has no cv-qualifiers and is never a reference.  Example,
<-> meaning type equivalence:

  namespace ns {
    class foo {
      typedef foo my_type;

      // decltype(class)  <->  ns::foo
      // decltype(class)  <->  my_type

      int bar() const {
        // decltype(class)  <->  ns::foo
      }

      float baz()  &&;

      decltype(class) make_self() { return decltype(class){}; }
      // semantically same as: foo make_self() { return foo{}; }

      // identical signature to make_self
      auto make_self2() -> decltype(class);

      // still identical signature
      decltype(class) make_self3();
    };
  }

  float ns::foo::baz() && {
    // decltype(class)  <->  ns::foo
  }

  auto ns::foo::make_self2() -> decltype(class) {
    return decltype(class);
  }

  template <typename T>
  class bar : public ns::foo {
    // decltype(class)  <->  bar<T>
  }

  decltype(class) ns::foo::make_self3()  // compile error, recommended
diagnostic: use trailing return type

  // same syntax even for structs, _not_ decltype(struct)
  struct s {
    // decltype(class)  <-> s
  };

  void func() {
    // decltype(class) --> compile error, func is not a member function
  }

  extern decltype(class) global; // compile error, variable declaration is
outside of a class definition

The main use case is in any kind of code generation, macro or not.  Even if
you're writing a Perl script or somesuch to generate code, it sometimes is
a bother to have to keep track of the name of the current class.  With
macros, it can be painful when the type is a template, has namespaces, or
otherwise is a complex aggregate name that you can't compose easily outside
of the initial definition.

The typedef of the class type (my_type in the example) is certainly an easy
workaround, if one that feels slightly ugly/unnecessary and from experience
a bit error-prone.  Removing the need for the typedef is relatively minor,
but then I don't currently see the addition of decltype(class) as
non-trivial.

Thoughts?

--

---
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_2959_3889959.1374775230926
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

A good currently-missing feature, which I'm unsure whether or not should fa=
ll under the reflection banner, would be the ability to look up the type of=
 the current class definition.<div><br></div><div>An example of some common=
 code, which can be a small burden:</div><div><br></div><div>&nbsp; &nbsp;c=
lass foo {</div><div>&nbsp; &nbsp; &nbsp;MACRO(foo); // duplicating class n=
ame, error-prone, plays very poorly with refactoring tools</div><div>&nbsp;=
 &nbsp;};</div><div><br></div><div>&nbsp; &nbsp;class bar {<br></div><div>&=
nbsp; &nbsp; &nbsp;typedef bar my_type; &nbsp;// wordy duplication even for=
 short-named example; still error-prone</div><div>&nbsp; &nbsp;} &nbsp;<br>=
</div><div><br></div><div>Having to duplicate the class name inside the cla=
ss's own definition can be ever so slightly error-prone. &nbsp;I'd like to =
think that most of those macro uses will just go away once compile-time ref=
lection is in, but since said reflection has not been proposed at all that =
I can tell, that's just a hopeful guess.</div><div><br></div><div>The idea =
is to offer a simple construct decltype(class). &nbsp;This is the type of t=
he current class definition. &nbsp;If inside a method, it is equal to the t=
ype of the class containing the method (very similar to decltype(*this) but=
 not quite the same). &nbsp;The most important difference from decltype(*th=
is) imo is the ability to use it outside of a method definition body, e.g. =
in return types.</div><div><br></div><div>decltype(class) has no cv-qualifi=
ers and is never a reference. &nbsp;Example, &lt;-&gt; meaning type equival=
ence:</div><div><br></div><div>&nbsp; namespace ns {</div><div>&nbsp; &nbsp=
; class foo {</div><div>&nbsp; &nbsp; &nbsp; typedef foo my_type;</div><div=
><br></div><div>&nbsp; &nbsp; &nbsp; // decltype(class)&nbsp;&nbsp;&lt;-&gt=
;&nbsp;&nbsp;ns::foo</div><div>&nbsp; &nbsp; &nbsp; // decltype(class) &nbs=
p;&lt;-&gt; &nbsp;my_type</div><div><br></div><div>&nbsp; &nbsp; &nbsp; int=
 bar() const {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; // decltype(class)&nbs=
p;&nbsp;&lt;-&gt;&nbsp;&nbsp;ns::foo</div><div>&nbsp; &nbsp; &nbsp; }</div>=
<div><br></div><div>&nbsp; &nbsp; &nbsp; float baz() &nbsp;&amp;&amp;;</div=
><div><br></div><div>&nbsp; &nbsp; &nbsp; decltype(class) make_self() { ret=
urn decltype(class){}; }</div><div>&nbsp; &nbsp; &nbsp; // semantically sam=
e as: foo make_self() { return foo{}; }</div><div><br></div><div>&nbsp; &nb=
sp; &nbsp; // identical signature to make_self</div><div>&nbsp; &nbsp; &nbs=
p; auto make_self2() -&gt; decltype(class);</div><div><br></div><div>&nbsp;=
 &nbsp; &nbsp; // still identical signature</div><div>&nbsp; &nbsp; &nbsp; =
decltype(class) make_self3();</div><div>&nbsp; &nbsp; };</div><div>&nbsp; }=
</div><div><br></div><div>&nbsp; float ns::foo::baz() &amp;&amp; {<br></div=
><div>&nbsp; &nbsp; // decltype(class) &nbsp;&lt;-&gt; &nbsp;ns::foo</div><=
div>&nbsp; }</div><div><br></div><div>&nbsp; auto ns::foo::make_self2() -&g=
t; decltype(class) {<br></div><div>&nbsp; &nbsp; return decltype(class);</d=
iv><div>&nbsp; }</div><div><br></div><div>&nbsp; template &lt;typename T&gt=
;</div><div>&nbsp; class bar : public ns::foo {</div><div>&nbsp; &nbsp; // =
decltype(class) &nbsp;&lt;-&gt; &nbsp;bar&lt;T&gt;</div><div>&nbsp; }</div>=
<div><br></div><div>&nbsp; decltype(class) ns::foo::make_self3() &nbsp;// c=
ompile error, recommended diagnostic: use trailing return type</div><div><b=
r></div><div>&nbsp; // same syntax even for structs, _not_ decltype(struct)=
</div><div>&nbsp; struct s {</div><div>&nbsp; &nbsp; // decltype(class) &nb=
sp;&lt;-&gt; s</div><div>&nbsp; };</div><div><br></div><div>&nbsp; void fun=
c() {</div><div>&nbsp; &nbsp; // decltype(class) --&gt; compile error, func=
 is not a member function</div><div>&nbsp; }</div><div><br></div><div>&nbsp=
; extern decltype(class) global; // compile error, variable declaration is =
outside of a class definition</div><div><br></div><div>The main use case is=
 in any kind of code generation, macro or not. &nbsp;Even if you're writing=
 a Perl script or somesuch to generate code, it sometimes is a bother to ha=
ve to keep track of the name of the current class. &nbsp;With macros, it ca=
n be painful when the type is a template, has namespaces, or otherwise is a=
 complex aggregate name that you can't compose easily outside of the initia=
l definition.</div><div><br></div><div>The typedef of the class type (my_ty=
pe in the example) is certainly an easy workaround, if one that feels sligh=
tly ugly/unnecessary and from experience a bit error-prone. &nbsp;Removing =
the need for the typedef is relatively minor, but then I don't currently se=
e the addition of decltype(class) as non-trivial.</div><div><br></div><div>=
Thoughts?<br></div>

<p></p>

-- <br />
&nbsp;<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 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2959_3889959.1374775230926--

.

------=_Part_3150_4534024.1374775702315
Content-Type: text/plain; charset=ISO-8859-1

HELL YES, PLEASE

--

---
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_3150_4534024.1374775702315
Content-Type: text/html; charset=ISO-8859-1

HELL YES, PLEASE<br>

<p></p>

-- <br />
&nbsp;<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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_3150_4534024.1374775702315--

.

--001a11c339e8e1350104e25baaae
Content-Type: text/plain; charset=ISO-8859-1

On 25 July 2013 21:08, <stackmachine@hotmail.com> wrote:

> HELL YES, PLEASE


Why not just consider removing one of the restrictions of where 'this' can
be used?
Is decltype(class) significantly different from 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/.



--001a11c339e8e1350104e25baaae
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 July 2013 21:08,  <span dir="ltr">&lt;<a href="mailto:stackmachine@hotmail.com" target="_blank">stackmachine@hotmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">HELL YES, PLEASE</blockquote><div><br></div><div>Why not just consider removing one of the restrictions of where &#39;this&#39; can be used?<br>
</div><div>Is decltype(class) significantly different from decltype(*this)?<br></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
&nbsp;<br />
&nbsp;<br />

--001a11c339e8e1350104e25baaae--

.

On Thu, Jul 25, 2013 at 1:14 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> Why not just consider removing one of the restrictions of where 'this' can
> be used?
> Is decltype(class) significantly different from decltype(*this)?

It's different enough (as originally written; clearly not set in stone
yet).  Consider:

  class foo {
    void bar() const {
      // decltype(*this)  <->  const foo&
      // decltype(class)  <->  foo
    }
  };

The end result being that in many cases, emulating decltype(class)
would require a much longer version of:

  std::remove_const<std::remove_reference<decltype(*this)>::type>::type

That doesn't account for volatile qualifiers or such, so the actual
replacement might not fit on one line.  Yuck.

I'd also argue strongly against allowing "this" outside of method
bodies.  It would essentially be a "fake" variable whose only
conceivable purpose is use with decltype (that I can think of,
anyway).  That is more complex both in terms of implementation and
specification than introducing decltype(class), unless I'm missing
something (which wouldn't surprise me).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.



.

--f46d04479fb75a7f0f04e25df4d8
Content-Type: text/plain; charset=ISO-8859-1

On 26 July 2013 01:22, Sean Middleditch <sean@middleditch.us> wrote:

> On Thu, Jul 25, 2013 at 1:14 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > Why not just consider removing one of the restrictions of where 'this'
> can
> > be used?
> > Is decltype(class) significantly different from decltype(*this)?
>
> It's different enough (as originally written; clearly not set in stone
> yet).  Consider:
>
>   class foo {
>     void bar() const {
>       // decltype(*this)  <->  const foo&
>       // decltype(class)  <->  foo
>     }
>   };
>
> The end result being that in many cases, emulating decltype(class)
> would require a much longer version of:
>
>   std::remove_const<std::remove_reference<decltype(*this)>::type>::type
>
> That doesn't account for volatile qualifiers or such, so the actual
> replacement might not fit on one line.  Yuck.
>
> I'd also argue strongly against allowing "this" outside of method
> bodies.  It would essentially be a "fake" variable whose only
> conceivable purpose is use with decltype (that I can think of,
> anyway).  That is more complex both in terms of implementation and
> specification than introducing decltype(class), unless I'm missing
> something (which wouldn't surprise me).
>
>
>
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).

Regarding the ugliness of the traits, this is more fuel to the fire I'm
kindling about
a potential shortcut trait proposal to have something that strips pointers
and references,
and your comment points out that it should likely strip cv-qualifiers too.

--

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



--f46d04479fb75a7f0f04e25df4d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 July 2013 01:22, Sean Middleditch <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div class=3D"im">On Thu,=
 Jul 25, 2013 at 1:14 PM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt; Why not just consider removing one of the restrictions of where &#39;t=
his&#39; can<br>
&gt; be used?<br>
&gt; Is decltype(class) significantly different from decltype(*this)?<br>
<br>
</div>It&#39;s different enough (as originally written; clearly not set in =
stone<br>
yet). =A0Consider:<br>
<br>
=A0 class foo {<br>
=A0 =A0 void bar() const {<br>
=A0 =A0 =A0 // decltype(*this) =A0&lt;-&gt; =A0const foo&amp;<br>
=A0 =A0 =A0 // decltype(class) =A0&lt;-&gt; =A0foo<br>
=A0 =A0 }<br>
=A0 };<br>
<br>
The end result being that in many cases, emulating decltype(class)<br>
would require a much longer version of:<br>
<br>
=A0 std::remove_const&lt;std::remove_reference&lt;decltype(*this)&gt;::type=
&gt;::type<br>
<br>
That doesn&#39;t account for volatile qualifiers or such, so the actual<br>
replacement might not fit on one line. =A0Yuck.<br>
<br>
I&#39;d also argue strongly against allowing &quot;this&quot; outside of me=
thod<br>
bodies. =A0It would essentially be a &quot;fake&quot; variable whose only<b=
r>
conceivable purpose is use with decltype (that I can think of,<br>
anyway). =A0That is more complex both in terms of implementation and<br>
specification than introducing decltype(class), unless I&#39;m missing<br>
something (which wouldn&#39;t surprise me).<br>
<div class=3D""><div class=3D"h5"><br><br></div></div></blockquote><div><br=
></div><div>The use of the type and value category of &#39;this&#39; is alr=
eady allowed in static member<br>functions as per [expr.prim.general]/3. Al=
lowing similar uses in the class definition<br>
</div><div>has its problems, but decltype(class) likely doesn&#39;t solve t=
hose problems (the type may<br>be incomplete because the class definition i=
s not yet known sufficiently, all<br>sorts of chicken-and-egg problems aris=
e). <br>
<br></div><div>Regarding the ugliness of the traits, this is more fuel to t=
he fire I&#39;m kindling about<br>a potential shortcut trait proposal to ha=
ve something that strips pointers and references,<br>and your comment point=
s out that it should likely strip cv-qualifiers too.<br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 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 />
&nbsp;<br />
&nbsp;<br />

--f46d04479fb75a7f0f04e25df4d8--

.

On Thu, Jul 25, 2013 at 3:57 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
>
> Regarding the ugliness of the traits, this is more fuel to the fire I'm
> kindling about
> a potential shortcut trait proposal to have something that strips pointers
> and references,
> and your comment points out that it should likely strip cv-qualifiers too.

That would be good on it's own, yes, you have my completely irrelevant
support for the idea. :)

Syntactical considerations and exact semantic debates aside, are there
any further opinions on the basic idea of a class-scope
decltype(this)/decltype(class) itself?

--

---
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_116_8040373.1374824683890
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le vendredi 26 juillet 2013 00:57:46 UTC+2, Ville Voutilainen a =E9crit :

>
> On 26 July 2013 01:22, Sean Middleditch <se...@middleditch.us<javascript:=
>
> > wrote:
>
>> The end result being that in many cases, emulating decltype(class)
>> would require a much longer version of:
>>
>>   std::remove_const<std::remove_reference<decltype(*this)>::type>::type
>>
>> That doesn't account for volatile qualifiers or such, so the actual
>> replacement might not fit on one line.  Yuck.
>>
>
> Regarding the ugliness of the traits, this is more fuel to the fire I'm=
=20
> kindling about
> a potential shortcut trait proposal to have something that strips pointer=
s=20
> and references,
> and your comment points out that it should likely strip cv-qualifiers too=
..
>
=20
A remove_cvref that does the same as remove_reference then remove_cv? I use=
=20
that locally. But in the case here, it seems that std::decay would be fine.=
=20
Now I see "strips pointers and references" in your message, and stripping=
=20
pointers (recursively?) seems quite different, it isn't clear where you=20
would want that. I guess I'll see when your proposal arrives ;-)

--=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_116_8040373.1374824683890
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le vendredi 26 juillet 2013 00:57:46 UTC+2, Ville Voutilainen a =E9crit&nbs=
p;:<br><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"><div><=
br><div class=3D"gmail_quote">On 26 July 2013 01:22, Sean Middleditch <span=
 dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"eHjStZbYNq8J">se...@middleditch.us</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">

The end result being that in many cases, emulating decltype(class)<br>
would require a much longer version of:<br>
<br>
&nbsp; std::remove_const&lt;std::remove_<wbr>reference&lt;decltype(*this)&g=
t;::<wbr>type&gt;::type<br>
<br>
That doesn't account for volatile qualifiers or such, so the actual<br>
replacement might not fit on one line. &nbsp;Yuck.<br></blockquote><div>
<br></div><div>Regarding the ugliness of the traits, this is more fuel to t=
he fire I'm kindling about<br>a potential shortcut trait proposal to have s=
omething that strips pointers and references,<br>and your comment points ou=
t that it should likely strip cv-qualifiers too.<br>
</div></div></div></div></blockquote><div>&nbsp;<br>A remove_cvref that doe=
s the same as remove_reference then remove_cv? I use that locally. But in t=
he case here, it seems that std::decay would be fine. Now I see "strips poi=
nters and references" in your message, and stripping pointers (recursively?=
) seems quite different, it isn't clear where you would want that. I guess =
I'll see when your proposal arrives ;-)<br></div>

<p></p>

-- <br />
&nbsp;<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 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_116_8040373.1374824683890--

.

--089e013cbae876c1c304e2655437
Content-Type: text/plain; charset=ISO-8859-1

On 26 July 2013 04:21, Sean Middleditch <sean@middleditch.us> wrote:

> On Thu, Jul 25, 2013 at 3:57 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> >
> > Regarding the ugliness of the traits, this is more fuel to the fire I'm
> > kindling about
> > a potential shortcut trait proposal to have something that strips
> pointers
> > and references,
> > and your comment points out that it should likely strip cv-qualifiers
> too.
>
> That would be good on it's own, yes, you have my completely irrelevant
> support for the idea. :)
>
> Syntactical considerations and exact semantic debates aside, are there
> any further opinions on the basic idea of a class-scope
> decltype(this)/decltype(class) itself?
>
>
>
I think we need The Smith here. :) The various considerations of class
completeness
are perhaps better explained by him...

--

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



--089e013cbae876c1c304e2655437
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 July 2013 04:21, Sean Middleditch <span dir=3D"ltr">&lt;<a hr=
ef=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:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Thu, Jul 25, 2013 at 3:=
57 PM, Ville Voutilainen<br>
&lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>&gt; wrote:<br>
&gt;<br>
&gt; Regarding the ugliness of the traits, this is more fuel to the fire I&=
#39;m<br>
&gt; kindling about<br>
&gt; a potential shortcut trait proposal to have something that strips poin=
ters<br>
&gt; and references,<br>
&gt; and your comment points out that it should likely strip cv-qualifiers =
too.<br>
<br>
</div>That would be good on it&#39;s own, yes, you have my completely irrel=
evant<br>
support for the idea. :)<br>
<br>
Syntactical considerations and exact semantic debates aside, are there<br>
any further opinions on the basic idea of a class-scope<br>
decltype(this)/decltype(class) itself?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br><br></div></div></blockquote><d=
iv><br></div><div>I think we need The Smith here. :) The various considerat=
ions of class completeness<br>are perhaps better explained by him...<br></d=
iv>
<div>=A0</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<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 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 />
&nbsp;<br />
&nbsp;<br />

--089e013cbae876c1c304e2655437--

.

--047d7bb03d3625c59704e2656392
Content-Type: text/plain; charset=ISO-8859-1

On 26 July 2013 10:44, Marc <marc.glisse@gmail.com> wrote:

>
> Regarding the ugliness of the traits, this is more fuel to the fire I'm
>> kindling about
>> a potential shortcut trait proposal to have something that strips
>> pointers and references,
>> and your comment points out that it should likely strip cv-qualifiers too.
>>
>
> A remove_cvref that does the same as remove_reference then remove_cv? I
> use that locally. But in the case here, it seems that std::decay would be
> fine. Now I see "strips pointers and references" in your message, and
> stripping pointers (recursively?) seems quite different, it isn't clear
> where you would want that. I guess I'll see when your proposal arrives ;-)
>

Here's a somewhat motivating case. It doesn't take cv-qualifiers into
account yet.

#include <functional>

using namespace std;

template <class T>
struct plain_type
{
    typedef typename remove_pointer<typename remove_reference<T>::type>::
type type;
};

struct X {void f() {}};

template <class T> void invoke_it(T&& t)
{
  bind(&plain_type<T>::type::f, t)();
}

int main()
{
  X x;
  invoke_it(x);
  invoke_it(&x);
  invoke_it(X());
  X* xp = &x;
  invoke_it(xp);
}

--

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



--047d7bb03d3625c59704e2656392
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 26 July 2013 10:44, Marc <span dir=3D"ltr">&lt;<a href=3D"mailto=
:marc.glisse@gmail.com" target=3D"_blank">marc.glisse@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><br><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div class=3D"im"><div>Reg=
arding the ugliness of the traits, this is more fuel to the fire I&#39;m ki=
ndling about<br>a potential shortcut trait proposal to have something that =
strips pointers and references,<br>
and your comment points out that it should likely strip cv-qualifiers too.<=
br>
</div></div></div></div></div></blockquote><div>=A0<br>A remove_cvref that =
does the same as remove_reference then remove_cv? I use that locally. But i=
n the case here, it seems that std::decay would be fine. Now I see &quot;st=
rips pointers and references&quot; in your message, and stripping pointers =
(recursively?) seems quite different, it isn&#39;t clear where you would wa=
nt that. I guess I&#39;ll see when your proposal arrives ;-)<br>
</div></blockquote><div><br></div><div>Here&#39;s a somewhat motivating cas=
e. It doesn&#39;t take cv-qualifiers into account yet.<br><br>#include &lt;=
functional&gt;<br>
<br>
using namespace std;<br>
<br>
template &lt;class T&gt;<br>
struct plain_type<br>
{<br>
=A0 =A0 typedef typename remove_pointer&lt;typename remove_reference&lt;T&g=
t;::type&gt;::<div id=3D":7g8">type type;<br>
<div class=3D"im">};<br>
<br>
struct X {void f() {}};<br>
<br>
template &lt;class T&gt; void invoke_it(T&amp;&amp; t)<br>
{<br>
</div>=A0 bind(&amp;plain_type&lt;T&gt;::type::f, t)();<br>
<div class=3D"im">}<br>
<br>
int main()<br>
{<br>
=A0 X x;<br>
=A0 invoke_it(x);<br>
=A0 invoke_it(&amp;x);<br>
=A0 invoke_it(X());<br>
</div>=A0 X* xp =3D &amp;x;<br>
=A0 invoke_it(xp);<br>
}<br></div></div></div></div></div>

<p></p>

-- <br />
&nbsp;<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 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 />
&nbsp;<br />
&nbsp;<br />

--047d7bb03d3625c59704e2656392--

.