------=_Part_220_1023468.1375199745925
Content-Type: text/plain; charset=ISO-8859-1

I'm thinking of writing a proposal to expand the valid uses of the
'typename' keyword.  The basic idea is fairly simple.  Within any
particular lexical scope, if the programmer wishes to instruct the compiler
that a particular identifier should be considered a type, it may be
prefaced with the typename keyword. Thus:

typename X; // forward declare a type 'X';
typename X::value; // forward declare a type 'value' that is nested within
type 'X' (accessibility problems... more on that later)

template <typename T>
void func ()
{
    typename T::value; // 'T::value' will always be a type within this scope
}

This would help solve several problems:


   1. Using 'class' or 'struct' in forward declarations.  Both work, but it
   is awfully confusing.  'typename' would become the "appropriate" way to do
   this.
   2. Removes the requirement for a full class declaration for nested
   types.  There could still be accessibility problems, but I think we could
   still issue diagnostics for these at a later point (when we have the full
   class declaration).  An implementation of that would probably go a long
   ways I would assume.
   3. In templates, we wouldn't have to resort to using type aliases to
   avoid putting typename in front of an identifier every time we used it. (I
   thought this already worked, but ideone.com disagreed).


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

I'm thinking of writing a proposal to expand the valid uses of the 'typenam=
e' keyword. &nbsp;The basic idea is fairly simple. &nbsp;Within any particu=
lar lexical scope, if the programmer wishes to instruct the compiler that a=
 particular identifier should be considered a type, it may be prefaced with=
 the typename keyword. Thus:<div><br></div><div><font face=3D"courier new, =
monospace">typename X; // forward declare a type 'X';</font></div><div><fon=
t face=3D"courier new, monospace">typename X::value; // forward declare a t=
ype 'value' that is nested within type 'X' (accessibility problems... more =
on that later)</font></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><font face=3D"courier new, monospace">template &lt;typenam=
e T&gt;</font></div><div><font face=3D"courier new, monospace">void func ()=
</font></div><div><font face=3D"courier new, monospace">{</font></div><div>=
<font face=3D"courier new, monospace">&nbsp; &nbsp; typename T::value; // '=
T::value' will always be a type within this scope</font></div><div><font fa=
ce=3D"courier new, monospace">}</font></div><div><br></div><div>This would =
help solve several problems:</div><div><br></div><div><ol><li>Using 'class'=
 or 'struct' in forward declarations. &nbsp;Both work, but it is awfully co=
nfusing. &nbsp;'typename' would become the "appropriate" way to do this.<br=
></li><li>Removes the requirement for a full class declaration for nested t=
ypes. &nbsp;There could still be accessibility problems, but I think we cou=
ld still issue diagnostics for these at a later point (when we have the ful=
l class declaration). &nbsp;An implementation of that would probably go a l=
ong ways I would assume.<br></li><li>In templates, we wouldn't have to reso=
rt to using type aliases to avoid putting typename in front of an identifie=
r every time we used it. (I thought this already worked, but ideone.com dis=
agreed).<br></li></ol></div><div><br></div><div>Thoughts?</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_220_1023468.1375199745925--

.

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

On 30 July 2013 18:55, Michael Price - Dev <michael.b.price.dev@gmail.com>wrote:

> I'm thinking of writing a proposal to expand the valid uses of the
> 'typename' keyword.  The basic idea is fairly simple.  Within any
> particular lexical scope, if the programmer wishes to instruct the compiler
> that a particular identifier should be considered a type, it may be
> prefaced with the typename keyword. Thus:
>
> typename X; // forward declare a type 'X';
> typename X::value; // forward declare a type 'value' that is nested within
> type 'X' (accessibility problems... more on that later)
>
> template <typename T>
> void func ()
> {
>     typename T::value; // 'T::value' will always be a type within this
> scope
> }
>
> This would help solve several problems:
>
>
>    1. Using 'class' or 'struct' in forward declarations.  Both work, but
>    it is awfully confusing.  'typename' would become the "appropriate" way to
>    do this.
>
>
Do you expect typename to cover non-class types, too, since it already does
that for its traditional uses?


>
>    1.
>    2. Removes the requirement for a full class declaration for nested
>    types.  There could still be accessibility problems, but I think we could
>    still issue diagnostics for these at a later point (when we have the full
>    class declaration).  An implementation of that would probably go a long
>    ways I would assume.
>
> This is oft-requested, so I'm certainly interested in it.


>
>    1.
>    2. In templates, we wouldn't have to resort to using type aliases to
>    avoid putting typename in front of an identifier every time we used it. (I
>    thought this already worked, but ideone.com disagreed).
>
>
Would you like to elaborate? I can do eg.

template <class T> void f()
{
   using type = typename T::type;
   type x;
   type y;
}

struct X
{
   typedef int type;
};

int main()
{
   f<X>();
}

--

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



--047d7bd766de98e02d04e2bcbb42
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 30 July 2013 18:55, Michael Price - Dev <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:michael.b.price.dev@gmail.com" target=3D"_blank">michael.b.=
price.dev@gmail.com</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">I&#39;m thinking of writi=
ng a proposal to expand the valid uses of the &#39;typename&#39; keyword. =
=A0The basic idea is fairly simple. =A0Within any particular lexical scope,=
 if the programmer wishes to instruct the compiler that a particular identi=
fier should be considered a type, it may be prefaced with the typename keyw=
ord. Thus:<div>
<br></div><div><font face=3D"courier new, monospace">typename X; // forward=
 declare a type &#39;X&#39;;</font></div><div><font face=3D"courier new, mo=
nospace">typename X::value; // forward declare a type &#39;value&#39; that =
is nested within type &#39;X&#39; (accessibility problems... more on that l=
ater)</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">template &lt;typename T&gt;</font></div><div><f=
ont face=3D"courier new, monospace">void func ()</font></div><div><font fac=
e=3D"courier new, monospace">{</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 typename T::value; // &#=
39;T::value&#39; will always be a type within this scope</font></div><div><=
font face=3D"courier new, monospace">}</font></div><div><br></div><div>This=
 would help solve several problems:</div>
<div><br></div><div><ol><li>Using &#39;class&#39; or &#39;struct&#39; in fo=
rward declarations. =A0Both work, but it is awfully confusing. =A0&#39;type=
name&#39; would become the &quot;appropriate&quot; way to do this.<br></li>
</ol></div></blockquote><div><br></div><div>Do you expect typename to cover=
 non-class types, too, since it already does that for its traditional uses?=
<br>=A0<br></div><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><ol><li></li><li>Removes the requirement for a full class declaration =
for nested types. =A0There could still be accessibility problems, but I thi=
nk we could still issue diagnostics for these at a later point (when we hav=
e the full class declaration). =A0An implementation of that would probably =
go a long ways I would assume.<br>
</li></ol></div></blockquote><div>This is oft-requested, so I&#39;m certain=
ly interested in it.<br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
<div><ol><li></li><li>In templates, we wouldn&#39;t have to resort to using=
 type aliases to avoid putting typename in front of an identifier every tim=
e we used it. (I thought this already worked, but <a href=3D"http://ideone.=
com" target=3D"_blank">ideone.com</a> disagreed).<br>
</li></ol></div></blockquote><div><br></div><div>Would you like to elaborat=
e? I can do eg.<br><br>template &lt;class T&gt; void f() <br>{<br>=A0=A0 us=
ing type =3D typename T::type; <br>=A0=A0 type x; <br>=A0=A0 type y;<br>} <=
br><br>struct X <br>
{<br>=A0=A0 typedef int type;<br>}; <br><br>int main() <br>{<br>=A0=A0 f&lt=
;X&gt;();<br>}<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 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 />

--047d7bd766de98e02d04e2bcbb42--

.

------=_Part_2342_5086728.1375207153664
Content-Type: text/plain; charset=ISO-8859-1


we have near equal tool to this in C++11:
template<typename T>
using value = typename T::value;

template <typename T>
void func ()
{
   typename value<T>;
}


--

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

<br>we have near equal tool to this in C++11:<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;"><cod=
e class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color:=
 #008;" class=3D"styled-by-prettify">template</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> value </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">value</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br><br></span><div><font face=3D"courier new, m=
onospace"><span style=3D"color: #008;" class=3D"styled-by-prettify">templat=
e</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;</span></font></div><div><font=
 face=3D"courier new, monospace"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> func </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">()</span></font></div><div><font face=3D"courier new, monospace"><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span></font></div>=
<div><font face=3D"courier new, monospace"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> &nbsp; &nbsp;</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> value</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;;</span></font></div><div><font face=3D"courier new, monospace=
"><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></font>=
</div></div></code></div><br><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 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_2342_5086728.1375207153664--

.

------=_Part_334_17305341.1375411324832
Content-Type: text/plain; charset=ISO-8859-1


On Tuesday, July 30, 2013 11:02:15 AM UTC-5, Ville Voutilainen wrote:
>
>
> On 30 July 2013 18:55, Michael Price - Dev <michael.b...@gmail.com<javascript:>
> > wrote:
>
>> I'm thinking of writing a proposal to expand the valid uses of the
>> 'typename' keyword.  The basic idea is fairly simple.  Within any
>> particular lexical scope, if the programmer wishes to instruct the compiler
>> that a particular identifier should be considered a type, it may be
>> prefaced with the typename keyword. Thus:
>>
>> typename X; // forward declare a type 'X';
>> typename X::value; // forward declare a type 'value' that is nested
>> within type 'X' (accessibility problems... more on that later)
>>
>> template <typename T>
>> void func ()
>> {
>>     typename T::value; // 'T::value' will always be a type within this
>> scope
>> }
>>
>> This would help solve several problems:
>>
>>
>>    1. Using 'class' or 'struct' in forward declarations.  Both work, but
>>    it is awfully confusing.  'typename' would become the "appropriate" way to
>>    do this.
>>
>>
> Do you expect typename to cover non-class types, too, since it already
> does that for its traditional uses?
>

I had not thought about enumerations, but I'd say that the current forward
declaration syntax is just fine there.  Forward declaring a scoped
enumeration State nested in a class X would look like:

typename X;
enum class X::State : int;

What other non-class types were you thinking of? Or rather, are there any
that I'm somehow forgetting?  Unions maybe?

>
>
>>
>>    1.
>>    2. Removes the requirement for a full class declaration for nested
>>    types.  There could still be accessibility problems, but I think we could
>>    still issue diagnostics for these at a later point (when we have the full
>>    class declaration).  An implementation of that would probably go a long
>>    ways I would assume.
>>
>> This is oft-requested, so I'm certainly interested in it.
>
>
>>
>>    1.
>>    2. In templates, we wouldn't have to resort to using type aliases to
>>    avoid putting typename in front of an identifier every time we used it. (I
>>    thought this already worked, but ideone.com disagreed).
>>
>>
> Would you like to elaborate? I can do eg.
>
> template <class T> void f()
> {
>    using type = typename T::type;
>    type x;
>    type y;
> }
>
> struct X
> {
>    typedef int type;
> };
>
> int main()
> {
>    f<X>();
> }
>

Yes, currently, one can do that, although I personally find it distasteful
to have to grab another identifier in scope to avoid repeated use of
typename.  Here is a situation where the typedef solution starts to wear
particularly thin (based off of yours)

template <class T, class U> void f()
{
    using t_type = typename T::type;
    using u_type = typename U::type; // What a bummer! Good thing there's
only one nested type name this worries about!

    t_type x;
    u_type y;

    /* I'd rather do
    typename T::type;
    typename U::type;

    T::type x;
    U::type y;
    */
}

struct X
{
    typedef int type;
};

int main ()
{
    f<X, X>();
}


On a procedural note, clearly this wouldn't be C++14 material.  Should I
rush to get this submitted or hold off till the post-Chicago mailings (if I
proceed)?

--

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

<br>On Tuesday, July 30, 2013 11:02:15 AM UTC-5, Ville Voutilainen wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br><div c=
lass=3D"gmail_quote">On 30 July 2013 18:55, Michael Price - Dev <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"STJPGuRXJqMJ">michael.b...@gmail.com</a><wbr>&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">I'm thinking of writing a=
 proposal to expand the valid uses of the 'typename' keyword. &nbsp;The bas=
ic idea is fairly simple. &nbsp;Within any particular lexical scope, if the=
 programmer wishes to instruct the compiler that a particular identifier sh=
ould be considered a type, it may be prefaced with the typename keyword. Th=
us:<div>
<br></div><div><font face=3D"courier new, monospace">typename X; // forward=
 declare a type 'X';</font></div><div><font face=3D"courier new, monospace"=
>typename X::value; // forward declare a type 'value' that is nested within=
 type 'X' (accessibility problems... more on that later)</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">template &lt;typename T&gt;</font></div><div><f=
ont face=3D"courier new, monospace">void func ()</font></div><div><font fac=
e=3D"courier new, monospace">{</font></div>
<div><font face=3D"courier new, monospace">&nbsp; &nbsp; typename T::value;=
 // 'T::value' will always be a type within this scope</font></div><div><fo=
nt face=3D"courier new, monospace">}</font></div><div><br></div><div>This w=
ould help solve several problems:</div>
<div><br></div><div><ol><li>Using 'class' or 'struct' in forward declaratio=
ns. &nbsp;Both work, but it is awfully confusing. &nbsp;'typename' would be=
come the "appropriate" way to do this.<br></li>
</ol></div></blockquote><div><br></div><div>Do you expect typename to cover=
 non-class types, too, since it already does that for its traditional uses?=
<br></div></div></div></div></blockquote><div><br></div><div>I had not thou=
ght about enumerations, but I'd say that the current forward declaration sy=
ntax is just fine there. &nbsp;Forward declaring a scoped enumeration State=
 nested in a class X would look like:</div><div><br></div><div>typename X;<=
/div><div>enum class X::State : int;</div><div><br></div><div>What other no=
n-class types were you thinking of? Or rather, are there any that I'm someh=
ow forgetting? &nbsp;Unions maybe?</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>&nbsp;<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><ol><li></li><li>Removes the requirement for a full class declaration =
for nested types. &nbsp;There could still be accessibility problems, but I =
think we could still issue diagnostics for these at a later point (when we =
have the full class declaration). &nbsp;An implementation of that would pro=
bably go a long ways I would assume.<br>
</li></ol></div></blockquote><div>This is oft-requested, so I'm certainly i=
nterested in it.<br></div><div>&nbsp;</div><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><ol><li></li><li>In templates, we wouldn't have to resort to using typ=
e aliases to avoid putting typename in front of an identifier every time we=
 used it. (I thought this already worked, but <a href=3D"http://ideone.com"=
 target=3D"_blank">ideone.com</a> disagreed).<br>
</li></ol></div></blockquote><div><br></div><div>Would you like to elaborat=
e? I can do eg.<br><br>template &lt;class T&gt; void f() <br>{<br>&nbsp;&nb=
sp; using type =3D typename T::type; <br>&nbsp;&nbsp; type x; <br>&nbsp;&nb=
sp; type y;<br>} <br><br>struct X <br>
{<br>&nbsp;&nbsp; typedef int type;<br>}; <br><br>int main() <br>{<br>&nbsp=
;&nbsp; f&lt;X&gt;();<br>}<br></div></div></div></div></blockquote><div><br=
></div><div>Yes, currently, one can do that, although I personally find it =
distasteful to have to grab another identifier in scope to avoid repeated u=
se of typename. &nbsp;Here is a situation where the typedef solution starts=
 to wear particularly thin (based off of yours)</div><div><br></div><div>te=
mplate &lt;class T, class U&gt; void f()</div><div>{</div><div>&nbsp; &nbsp=
; using t_type =3D typename T::type;</div><div>&nbsp; &nbsp; using u_type =
=3D typename U::type; // What a bummer! Good thing there's only one nested =
type name this worries about!</div><div><br></div><div>&nbsp; &nbsp; t_type=
 x;</div><div>&nbsp; &nbsp; u_type y;</div><div><br></div><div>&nbsp; &nbsp=
; /* I'd rather do</div><div>&nbsp; &nbsp; typename T::type;</div><div>&nbs=
p; &nbsp; typename U::type;</div><div><br></div><div>&nbsp; &nbsp; T::type =
x;</div><div>&nbsp; &nbsp; U::type y;</div><div>&nbsp; &nbsp; */</div><div>=
}</div><div><br></div><div>struct X</div><div>{</div><div>&nbsp; &nbsp; typ=
edef int type;</div><div>};</div><div><br></div><div>int main ()</div><div>=
{</div><div>&nbsp; &nbsp; f&lt;X, X&gt;();<br>}</div><div><br></div><div><b=
r></div><div>On a procedural note, clearly this wouldn't be C++14 material.=
 &nbsp;Should I rush to get this submitted or hold off till the post-Chicag=
o mailings (if I proceed)?</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_334_17305341.1375411324832--

.

------=_Part_283_19634476.1375411427257
Content-Type: text/plain; charset=ISO-8859-1

That "solves" part of the problem, although, you'd have to define such a
thing for every nested type name you wanted to use (macros could help...
but yuck).  It also doesn't solve any forward declaration problems (which
admittedly might be much less once the module-nirvana has arrived).

On Tuesday, July 30, 2013 12:59:13 PM UTC-5, inkwizyt...@gmail.com wrote:
>
>
> we have near equal tool to this in C++11:
> template<typename T>
> using value = typename T::value;
>
> template <typename T>
> void func ()
> {
>    typename value<T>;
> }
>
>
>

--

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

That "solves" part of the problem, although, you'd have to define such a th=
ing for every nested type name you wanted to use (macros could help... but =
yuck). &nbsp;It also doesn't solve any forward declaration problems (which =
admittedly might be much less once the module-nirvana has arrived).<br><br>=
On Tuesday, July 30, 2013 12:59:13 PM UTC-5, inkwizyt...@gmail.com wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><br>we have near equal tool to t=
his in C++11:<br><div style=3D"background-color:rgb(250,250,250);border-col=
or:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-wor=
d"><code><div><span style=3D"color:#008">template</span><span style=3D"colo=
r:#660">&lt;</span><span style=3D"color:#008">typename</span><span style=3D=
"color:#000"> T</span><span style=3D"color:#660">&gt;</span><span style=3D"=
color:#000"><br></span><span style=3D"color:#008">using</span><span style=
=3D"color:#000"> value </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#008">typename</span><span =
style=3D"color:#000"> T</span><span style=3D"color:#660">::</span><span sty=
le=3D"color:#000">value</span><span style=3D"color:#660">;</span><span styl=
e=3D"color:#000"><br><br></span><div><font face=3D"courier new, monospace">=
<span style=3D"color:#008">template</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">&lt;</span><span style=3D"color:#008">typename=
</span><span style=3D"color:#000"> T</span><span style=3D"color:#660">&gt;<=
/span></font></div><div><font face=3D"courier new, monospace"><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> func </span><span st=
yle=3D"color:#660">()</span></font></div><div><font face=3D"courier new, mo=
nospace"><span style=3D"color:#660">{</span></font></div><div><font face=3D=
"courier new, monospace"><span style=3D"color:#000"> &nbsp; &nbsp;</span><s=
pan style=3D"color:#008">typename</span><span style=3D"color:#000"> value</=
span><span style=3D"color:#660">&lt;</span><span style=3D"color:#000">T</sp=
an><span style=3D"color:#660">&gt;;</span></font></div><div><font face=3D"c=
ourier new, monospace"><span style=3D"color:#660">}</span></font></div></di=
v></code></div><br><br></blockquote>

<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_283_19634476.1375411427257--

.

------=_Part_110_11726100.1375887003051
Content-Type: text/plain; charset=ISO-8859-1



On Tuesday, July 30, 2013 5:55:45 PM UTC+2, Michael Price - Dev wrote:
>
> I'm thinking of writing a proposal to expand the valid uses of the
> 'typename' keyword.  The basic idea is fairly simple.  Within any
> particular lexical scope, if the programmer wishes to instruct the compiler
> that a particular identifier should be considered a type, it may be
> prefaced with the typename keyword. Thus:
>
> typename X; // forward declare a type 'X';
>

Unfortunately, there are ABI concerns with this. For example, if I now
declare a function

void f(X*);

what is its mangled name? It should be possible to use this function
without ever seeing more of X in a translation unit, so the compiler must
be able to determine the name of f based on this alone.
At the very least, you would have to require that X later becomes a real
type, i.e. there is a definition of a class or enum X somewhere, as opposed
to a typedef or using X. Here's the reason:
Imagine that in the implementation, you have this:

typedef int X;
void f(int*) { ... }

Clearly, f(int*) and f(X*) are the same function, so this should work,
right? But given the limited information the compiler has in a translation
unit where it never sees the definition of X, it can only give f the manged
name "f$P1X" (in this mangling scheme I just made up), whereas the
definition has the mangled name "f$I". Only if X is a real type does this
actually work.

And that's just for standards-compliant compilers. For some reason, way
back when Microsoft designed its mangling scheme, they decided that structs
and classes are different things, so they mangle whether a class is
declared with "struct" or "class" into the name. In other words, the
declaration "struct X; void f(X*);" won't link against the definition
"class X {}; void f(X*);" This is of course a bug in their ABI, but they're
not about to fix it, and having a third way to introduce a named type won't
make things easier.


> typename X::value; // forward declare a type 'value' that is nested within
> type 'X' (accessibility problems... more on that later)
>

Since nested types love to be typedefs (e.g. iterators in containers), the
problem is just exacerbated in this case.


>
> template <typename T>
> void func ()
> {
>     typename T::value; // 'T::value' will always be a type within this
> scope
> }
>

This idea, I love.


>
>    1. Using 'class' or 'struct' in forward declarations.  Both work, but
>    it is awfully confusing.  'typename' would become the "appropriate" way to
>    do this.
>
> As I described above, this is highly problematic.


>
>    1. Removes the requirement for a full class declaration for nested
>    types.  There could still be accessibility problems, but I think we could
>    still issue diagnostics for these at a later point (when we have the full
>    class declaration).  An implementation of that would probably go a long
>    ways I would assume.
>
> What if you never see the full definition in a particular translation unit?


>
>    1. In templates, we wouldn't have to resort to using type aliases to
>    avoid putting typename in front of an identifier every time we used it. (I
>    thought this already worked, but ideone.com disagreed).
>
>
As I said, I like this one. I'm not sure it's worth it, though - between
the ability to define local aliases and inkwizyt's workaround, the added
value is small.

--

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

<br><br>On Tuesday, July 30, 2013 5:55:45 PM UTC+2, Michael Price - Dev wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">I'm thinking of writing a p=
roposal to expand the valid uses of the 'typename' keyword. &nbsp;The basic=
 idea is fairly simple. &nbsp;Within any particular lexical scope, if the p=
rogrammer wishes to instruct the compiler that a particular identifier shou=
ld be considered a type, it may be prefaced with the typename keyword. Thus=
:<div><br></div><div><font face=3D"courier new, monospace">typename X; // f=
orward declare a type 'X';</font></div></blockquote><div><br></div><div>Unf=
ortunately, there are ABI concerns with this. For example, if I now declare=
 a function</div><div><br></div><div>void f(X*);</div><div><br></div><div>w=
hat is its mangled name? It should be possible to use this function without=
 ever seeing more of X in a translation unit, so the compiler must be able =
to determine the name of f based on this alone.</div><div>At the very least=
, you would have to require that X later becomes a real type, i.e. there is=
 a definition of a class or enum X somewhere, as opposed to a typedef or us=
ing X. Here's the reason:</div><div>Imagine that in the implementation, you=
 have this:</div><div><br></div><div>typedef int X;</div><div>void f(int*) =
{ ... }</div><div><br></div><div>Clearly, f(int*) and f(X*) are the same fu=
nction, so this should work, right? But given the limited information the c=
ompiler has in a translation unit where it never sees the definition of X, =
it can only give f the manged name "f$P1X" (in this mangling scheme I just =
made up), whereas the definition has the mangled name "f$I". Only if X is a=
 real type does this actually work.</div><div><br></div><div>And that's jus=
t for standards-compliant compilers. For some reason, way back when Microso=
ft designed its mangling scheme, they decided that structs and classes are =
different things, so they mangle whether a class is declared with "struct" =
or "class" into the name. In other words, the declaration "struct X; void f=
(X*);" won't link against the definition "class X {}; void f(X*);" This is =
of course a bug in their ABI, but they're not about to fix it, and having a=
 third way to introduce a named type won't make things easier.</div><div>&n=
bsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><font face=3D"c=
ourier new, monospace">typename X::value; // forward declare a type 'value'=
 that is nested within type 'X' (accessibility problems... more on that lat=
er)</font></div></blockquote><div><br></div><div>Since nested types love to=
 be typedefs (e.g. iterators in containers), the problem is just exacerbate=
d in this case.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div><font face=3D"courier new, monospace"><br></font></div><div><f=
ont face=3D"courier new, monospace">template &lt;typename T&gt;</font></div=
><div><font face=3D"courier new, monospace">void func ()</font></div><div><=
font face=3D"courier new, monospace">{</font></div><div><font face=3D"couri=
er new, monospace">&nbsp; &nbsp; typename T::value; // 'T::value' will alwa=
ys be a type within this scope</font></div><div><font face=3D"courier new, =
monospace">}</font></div></blockquote><div><br></div><div>This idea, I love=
..</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><=
ol><li>Using 'class' or 'struct' in forward declarations. &nbsp;Both work, =
but it is awfully confusing. &nbsp;'typename' would become the "appropriate=
" way to do this.<br></li></ol></div></blockquote><div>As I described above=
, this is highly problematic.</div><div>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div><ol><li>Removes the requirement for a full class=
 declaration for nested types. &nbsp;There could still be accessibility pro=
blems, but I think we could still issue diagnostics for these at a later po=
int (when we have the full class declaration). &nbsp;An implementation of t=
hat would probably go a long ways I would assume.<br></li></ol></div></bloc=
kquote><div>What if you never see the full definition in a particular trans=
lation unit?</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div><ol><li>In templates, we wouldn't have to resort to using type a=
liases to avoid putting typename in front of an identifier every time we us=
ed it. (I thought this already worked, but <a href=3D"http://ideone.com" ta=
rget=3D"_blank">ideone.com</a> disagreed).</li></ol></div></blockquote><div=
><br></div><div>As I said, I like this one. I'm not sure it's worth it, tho=
ugh - between the ability to define local aliases and inkwizyt's workaround=
, the added value is small.&nbsp;</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_110_11726100.1375887003051--

.

On Thu, Sep 04, 2014 at 01:55:09AM -0700, Andrzej Krzemie??ski wrote:
>
> I wonder if it would solve the problems I face. Can I use it to
> forward-declare template instantiations as well? Eg.:
>
> namespace std
> {
>   typename string;
> }
>
> std::string is not a "class", but I would like to be able to
> forward-declare it. (I am not sure if you could do that for namespace std,
> but it would still be useful for other namespaces). If this could be done,
> I consider the proposal very useful. I often need to turn a class into a
> class template and hate to be forced to rewrite all my forward declarations.

Yes, it would be nice to be able to do that, but the problem is that given

typename foo;

you can't know what

sizeof(foo*);

is.

/MF

--

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

.

2013-07-30 17:55 GMT+02:00 Michael Price - Dev <michael.b.price.dev@gmail.com>:
> I'm thinking of writing a proposal to expand the valid uses of the
> 'typename' keyword.  The basic idea is fairly simple.  Within any particular
> lexical scope, if the programmer wishes to instruct the compiler that a
> particular identifier should be considered a type, it may be prefaced with
> the typename keyword. Thus:
>
> typename X; // forward declare a type 'X';

What about using "auto" to say that "X" refers to a placeholder type:

    typedef auto X;

--

---
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_5608_40808791.1409866542733
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



W dniu czwartek, 4 wrze=C5=9Bnia 2014 19:09:34 UTC+2 u=C5=BCytkownik Magnus=
 Fromreide=20
napisa=C5=82:
>
> On Thu, Sep 04, 2014 at 01:55:09AM -0700, Andrzej Krzemie??ski wrote:=20
> >=20
> > I wonder if it would solve the problems I face. Can I use it to=20
> > forward-declare template instantiations as well? Eg.:=20
> >=20
> > namespace std=20
> > {=20
> >   typename string;=20
> > }=20
> >=20
> > std::string is not a "class", but I would like to be able to=20
> > forward-declare it. (I am not sure if you could do that for namespace=
=20
> std,=20
> > but it would still be useful for other namespaces). If this could be=20
> done,=20
> > I consider the proposal very useful. I often need to turn a class into =
a=20
> > class template and hate to be forced to rewrite all my forward=20
> declarations.=20
>
> Yes, it would be nice to be able to do that, but the problem is that give=
n=20
>
> typename foo;=20
>
> you can't know what=20
>
> sizeof(foo*);=20
>
> is.=20
>

Why?

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

<div dir=3D"ltr"><br><br>W dniu czwartek, 4 wrze=C5=9Bnia 2014 19:09:34 UTC=
+2 u=C5=BCytkownik Magnus Fromreide napisa=C5=82:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">On Thu, Sep 04, 2014 at 01:55:09AM -0700, Andrzej Krzemi=
e??ski wrote:
<br>&gt;=20
<br>&gt; I wonder if it would solve the problems I face. Can I use it to=20
<br>&gt; forward-declare template instantiations as well? Eg.:
<br>&gt;=20
<br>&gt; namespace std
<br>&gt; {
<br>&gt; &nbsp; typename string;
<br>&gt; }
<br>&gt;=20
<br>&gt; std::string is not a "class", but I would like to be able to=20
<br>&gt; forward-declare it. (I am not sure if you could do that for namesp=
ace std,=20
<br>&gt; but it would still be useful for other namespaces). If this could =
be done,=20
<br>&gt; I consider the proposal very useful. I often need to turn a class =
into a=20
<br>&gt; class template and hate to be forced to rewrite all my forward dec=
larations.
<br>
<br>Yes, it would be nice to be able to do that, but the problem is that gi=
ven
<br>
<br>typename foo;
<br>
<br>you can't know what
<br>
<br>sizeof(foo*);
<br>
<br>is.
<br></blockquote><div><br>Why?<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_5608_40808791.1409866542733--

.

------=_Part_3957_2034335944.1409867231961
Content-Type: text/plain; charset=UTF-8

On Thursday, September 4, 2014 10:09:34 AM UTC-7, Magnus Fromreide wrote:
>
> Yes, it would be nice to be able to do that, but the problem is that given
>
> typename foo;
>
> you can't know what
>
> sizeof(foo*);
>
> is.
>

You don't know that for forward declarations anyway. This doesn't change
that. It just makes it so that you don't need to care whether a type is
defined via `struct` or `class` or `using` or a template instantiation when
making a forward declaration, just like you don't need to care in any other
context in the language.

--

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

<div dir=3D"ltr">On Thursday, September 4, 2014 10:09:34 AM UTC-7, Magnus F=
romreide wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, it would b=
e nice to be able to do that, but the problem is that given
<br>
<br>typename foo;
<br>
<br>you can't know what
<br>
<br>sizeof(foo*);
<br>
<br>is.
<br></blockquote><div><br></div><div>You don't know that for forward declar=
ations anyway. This doesn't change that. It just makes it so that you don't=
 need to care whether a type is defined via `struct` or `class` or `using` =
or a template instantiation when making a forward declaration, just like yo=
u don't need to care in any other context in the language.</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_3957_2034335944.1409867231961--

.

On Thursday 04 September 2014 14:35:42 Andrzej Krzemie=C5=84ski wrote:
> > Yes, it would be nice to be able to do that, but the problem is that
> > given=20
> >=20
> > typename foo;=20
> >=20
> > you can't know what=20
> >=20
> > sizeof(foo*);=20
> >=20
> > is.=20
>=20
> Why?

Because given:

struct S { };

The following may be different:
 sizeof(S *)    // data pointer
 sizeof(void (*)())  // code pointer
 sizeof(void (S:: *)())  // pointer to member function
 sizeof(int S::*)   // pointer to member variable

And PMFs change size depending on the class that they refer to.

--=20
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

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

.

On Thursday 04 September 2014 14:47:11 Sean Middleditch wrote:
> You don't know that for forward declarations anyway.

Yes, you do.

There may be a problem with pointer to member functions if the class is only
forward-declared, but that only happens in legacy environments (like Visual
Studio without /vmg) and it technically disagrees with the standard.

> This doesn't change
> that. It just makes it so that you don't need to care whether a type is
> defined via `struct` or `class` or `using` or a template instantiation when
> making a forward declaration, just like you don't need to care in any other
> context in the language.

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

.

Sigh, I totally missed the significance of the * in the sizeof expression.

I see two options for dealing with that specific problem:
1) Make sizeof on uniform type declarations ill-formed.
2) Make the use of uniform type declarations for
non-class/struct/primitive types (including class/struct template
instantiations) ill-formed.
3) Make both ill-formed to be conservative and evolve the feature in a
future paper.

Those issues aside, the ABI/mangling issue is limiting enough to make
the cost/benefit for this feature rather high, though.

On a related note: could modules remove much of the need for this
feature? My understanding is that they'd rather greatly reduce the
need for many common need for any kind of forward declaration.

On Thu, Sep 4, 2014 at 3:31 PM, Thiago Macieira <thiago@macieira.org> wrote:
> On Thursday 04 September 2014 14:47:11 Sean Middleditch wrote:
>> You don't know that for forward declarations anyway.
>
> Yes, you do.
>
> There may be a problem with pointer to member functions if the class is only
> forward-declared, but that only happens in legacy environments (like Visual
> Studio without /vmg) and it technically disagrees with the standard.
>
>> This doesn't change
>> that. It just makes it so that you don't need to care whether a type is
>> defined via `struct` or `class` or `using` or a template instantiation when
>> making a forward declaration, just like you don't need to care in any other
>> context in the language.
>
> --
> 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 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/ZAfM7AO5n9Q/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/.

.

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

On Fri, Sep 5, 2014 at 12:26 AM, Sean Middleditch <sean@middleditch.us>
wrote:

> Sigh, I totally missed the significance of the * in the sizeof expression.
>
> I see two options for dealing with that specific problem:
> 1) Make sizeof on uniform type declarations ill-formed.
> 2) Make the use of uniform type declarations for
> non-class/struct/primitive types (including class/struct template
> instantiations) ill-formed.
> 3) Make both ill-formed to be conservative and evolve the feature in a
> future paper.
>
> Those issues aside, the ABI/mangling issue is limiting enough to make
> the cost/benefit for this feature rather high, though.
>
> On a related note: could modules remove much of the need for this
> feature? My understanding is that they'd rather greatly reduce the
> need for many common need for any kind of forward declaration.


Only to a limited extent. Here are three use cases for forward declarations
for types:

1) Resolving cyclic dependencies, for instance if the definition of type A
needs type B and the definition of type B needs type A.
2) Minimizing the set of translation units that is rebuilt when a type's
definition changes.
3) Minimizing the transitive include size of a translation unit.

Modules (in current proposals and implementations) only help for (3), and
if you replace forward declarations with module imports, you make (1) and
(2) worse.

On Thu, Sep 4, 2014 at 3:31 PM, Thiago Macieira <thiago@macieira.org> wrote:
> > On Thursday 04 September 2014 14:47:11 Sean Middleditch wrote:
> >> You don't know that for forward declarations anyway.
> >
> > Yes, you do.
> >
> > There may be a problem with pointer to member functions if the class is
> only
> > forward-declared, but that only happens in legacy environments (like
> Visual
> > Studio without /vmg) and it technically disagrees with the standard.
> >
> >> This doesn't change
> >> that. It just makes it so that you don't need to care whether a type is
> >> defined via `struct` or `class` or `using` or a template instantiation
> when
> >> making a forward declaration, just like you don't need to care in any
> other
> >> context in the language.
> >
> > --
> > 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 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/ZAfM7AO5n9Q/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/.

--001a113398c4744ae2050257869d
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 F=
ri, Sep 5, 2014 at 12:26 AM, Sean Middleditch <span dir=3D"ltr">&lt;<a href=
=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sigh, I totally missed t=
he significance of the * in the sizeof expression.<br>
<br>
I see two options for dealing with that specific problem:<br>
1) Make sizeof on uniform type declarations ill-formed.<br>
2) Make the use of uniform type declarations for<br>
non-class/struct/primitive types (including class/struct template<br>
instantiations) ill-formed.<br>
3) Make both ill-formed to be conservative and evolve the feature in a<br>
future paper.<br>
<br>
Those issues aside, the ABI/mangling issue is limiting enough to make<br>
the cost/benefit for this feature rather high, though.<br>
<br>
On a related note: could modules remove much of the need for this<br>
feature? My understanding is that they&#39;d rather greatly reduce the<br>
need for many common need for any kind of forward declaration.</blockquote>=
<div><br></div><div>Only to a limited extent. Here are three use cases for =
forward declarations for types:</div><div><br></div><div>1) Resolving cycli=
c dependencies, for instance if the definition of type A needs type B and t=
he definition of type B needs type A.</div><div>2) Minimizing the set of tr=
anslation units that is rebuilt when a type&#39;s definition changes.</div>=
<div>3) Minimizing the transitive include size of a translation unit.</div>=
<div><br></div><div>Modules (in current proposals and implementations) only=
 help for (3), and if you replace forward declarations with module imports,=
 you make (1) and (2) worse.</div><div><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span class=3D"">
On Thu, Sep 4, 2014 at 3:31 PM, Thiago Macieira &lt;<a href=3D"mailto:thiag=
o@macieira.org">thiago@macieira.org</a>&gt; wrote:<br>
&gt; On Thursday 04 September 2014 14:47:11 Sean Middleditch wrote:<br>
&gt;&gt; You don&#39;t know that for forward declarations anyway.<br>
&gt;<br>
&gt; Yes, you do.<br>
&gt;<br>
&gt; There may be a problem with pointer to member functions if the class i=
s only<br>
&gt; forward-declared, but that only happens in legacy environments (like V=
isual<br>
&gt; Studio without /vmg) and it technically disagrees with the standard.<b=
r>
&gt;<br>
&gt;&gt; This doesn&#39;t change<br>
&gt;&gt; that. It just makes it so that you don&#39;t need to care whether =
a type is<br>
&gt;&gt; defined via `struct` or `class` or `using` or a template instantia=
tion when<br>
&gt;&gt; making a forward declaration, just like you don&#39;t need to care=
 in any other<br>
&gt;&gt; context in the language.<br>
&gt;<br>
&gt; --<br>
&gt; Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" targ=
et=3D"_blank">kde.org</a><br>
&gt;=C2=A0 =C2=A0 Software Architect - Intel Open Source Technology Center<=
br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0PGP/GPG: 0x6EF45358; fingerprint:<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0E067 918B B660 DBD1 105C=C2=A0 966C 33F5 F00=
5 6EF4 5358<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
</span>&gt; You received this message because you are subscribed to a topic=
 in the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group=
..<br>
&gt; To unsubscribe from this topic, visit <a href=3D"https://groups.google=
..com/a/isocpp.org/d/topic/std-proposals/ZAfM7AO5n9Q/unsubscribe" target=3D"=
_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/ZAfM7A=
O5n9Q/unsubscribe</a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to <a=
 href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsub=
scribe@isocpp.org</a>.<br>
<span class=3D"im HOEnZb">&gt; To post to this group, send email to <a href=
=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.or=
g/group/std-proposals/</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 />

--001a113398c4744ae2050257869d--

.