------=_Part_620_2047658101.1467731917275
Content-Type: multipart/alternative;
 boundary="----=_Part_621_1434009533.1467731917275"

------=_Part_621_1434009533.1467731917275
Content-Type: text/plain; charset=UTF-8

This would be useful for macros that take the names of types as parameters.
 It would allow the parameter to optionally be a template type parameter.

To give a trivial example:

#define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
typename CLS::Some_type INSTNAME;

The proposed change would allow the macro to be used inside a template
definition with a template type parameter as the actual parameter for CLS,
as well as in the general case (where CLS is not a formal template
parameter).

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3d1ac72d-89c4-4532-83a9-d5b934fe8eeb%40isocpp.org.

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

<div dir=3D"ltr">This would be useful for macros that take the names of typ=
es as parameters. =C2=A0It would allow the parameter to optionally be a tem=
plate type parameter.<div><br></div><div>To give a trivial example:</div><d=
iv><br></div><div>#define INST_MBR_SOME_TYPE(CLS, INSTNAME) \</div><div>typ=
ename CLS::Some_type INSTNAME;</div><div><br></div><div>The proposed change=
 would allow the macro to be used inside a template definition with a templ=
ate type parameter as the actual parameter for CLS, as well as in the gener=
al case (where CLS is not a formal template parameter).</div></div>

<p></p>

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

------=_Part_621_1434009533.1467731917275--

------=_Part_620_2047658101.1467731917275--

.

------=_Part_3126_538039391.1467774443024
Content-Type: multipart/alternative;
 boundary="----=_Part_3127_2115365213.1467774443024"

------=_Part_3127_2115365213.1467774443024
Content-Type: text/plain; charset=UTF-8

I think your proposal would be much, much stronger if the only use case was
not one involving the usage of a macro.
I'm not saying there aren't other use cases, but simply that you should
provide them with any hypothetical proposal.

Regards,
Louis

On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas wrote:
>
> This would be useful for macros that take the names of types as
> parameters.  It would allow the parameter to optionally be a template type
> parameter.
>
> To give a trivial example:
>
> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
> typename CLS::Some_type INSTNAME;
>
> The proposed change would allow the macro to be used inside a template
> definition with a template type parameter as the actual parameter for CLS,
> as well as in the general case (where CLS is not a formal template
> parameter).
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2969e374-9fb6-4b68-a8f1-03039db8bb80%40isocpp.org.

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

<div dir=3D"ltr">I think your proposal would be much, much stronger if the =
only use case was not one involving the usage of a macro.<div>I&#39;m not s=
aying there aren&#39;t other use cases, but simply that you should provide =
them with any hypothetical proposal.</div><div><div><br></div><div>Regards,=
</div><div>Louis<br><br>On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">This w=
ould be useful for macros that take the names of types as parameters. =C2=
=A0It would allow the parameter to optionally be a template type parameter.=
<div><br></div><div>To give a trivial example:</div><div><br></div><div>#de=
fine INST_MBR_SOME_TYPE(CLS, INSTNAME) \</div><div>typename CLS::Some_type =
INSTNAME;</div><div><br></div><div>The proposed change would allow the macr=
o to be used inside a template definition with a template type parameter as=
 the actual parameter for CLS, as well as in the general case (where CLS is=
 not a formal template parameter).</div></div></blockquote></div></div></di=
v>

<p></p>

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

------=_Part_3127_2115365213.1467774443024--

------=_Part_3126_538039391.1467774443024--

.

------=_Part_4752_1041450922.1467778636199
Content-Type: multipart/alternative;
 boundary="----=_Part_4753_494307282.1467778636200"

------=_Part_4753_494307282.1467778636200
Content-Type: text/plain; charset=UTF-8

Unfortunately, I don't think there are any use cases that don't involve a
macro.

I ran into this issue in this code:



On Tuesday, July 5, 2016 at 11:07:23 PM UTC-4, Louis Dionne wrote:
>
> I think your proposal would be much, much stronger if the only use case
> was not one involving the usage of a macro.
> I'm not saying there aren't other use cases, but simply that you should
> provide them with any hypothetical proposal.
>
> Regards,
> Louis
>
> On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas wrote:
>>
>> This would be useful for macros that take the names of types as
>> parameters.  It would allow the parameter to optionally be a template type
>> parameter.
>>
>> To give a trivial example:
>>
>> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
>> typename CLS::Some_type INSTNAME;
>>
>> The proposed change would allow the macro to be used inside a template
>> definition with a template type parameter as the actual parameter for CLS,
>> as well as in the general case (where CLS is not a formal template
>> parameter).
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ca15acfb-8c28-4141-a7fe-d6e378d604ec%40isocpp.org.

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

<div dir=3D"ltr">Unfortunately, I don&#39;t think there are any use cases t=
hat don&#39;t involve a macro.<div><br></div><div>I ran into this issue in =
this code:</div><div><br></div><div><br><br>On Tuesday, July 5, 2016 at 11:=
07:23 PM UTC-4, Louis Dionne wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">I think your proposal would be much, much stronger i=
f the only use case was not one involving the usage of a macro.<div>I&#39;m=
 not saying there aren&#39;t other use cases, but simply that you should pr=
ovide them with any hypothetical proposal.</div><div><div><br></div><div>Re=
gards,</div><div>Louis<br><br>On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt =
Karas  wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This =
would be useful for macros that take the names of types as parameters. =C2=
=A0It would allow the parameter to optionally be a template type parameter.=
<div><br></div><div>To give a trivial example:</div><div><br></div><div>#de=
fine INST_MBR_SOME_TYPE(CLS, INSTNAME) \</div><div>typename CLS::Some_type =
INSTNAME;</div><div><br></div><div>The proposed change would allow the macr=
o to be used inside a template definition with a template type parameter as=
 the actual parameter for CLS, as well as in the general case (where CLS is=
 not a formal template parameter).</div></div></blockquote></div></div></di=
v></blockquote></div></div>

<p></p>

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

------=_Part_4753_494307282.1467778636200--

------=_Part_4752_1041450922.1467778636199--

.

------=_Part_13500_2086069358.1467780129777
Content-Type: multipart/alternative;
 boundary="----=_Part_13501_1513620347.1467780129786"

------=_Part_13501_1513620347.1467780129786
Content-Type: text/plain; charset=UTF-8

Unfortunately, I don't think there are any use cases that don't involve a
macro.

I ran into this issue in this code:

https://github.com/wkaras/C-plus-plus-library-bit-fields

in the testbf.cpp file in the BITF_CAT macro calls starting at line 561.
 BITF_CAT (defined in bitfield.h) originally directly constructed a Bwf::Bf
instance.  But this did not work here since Bf was a dependant name.  My
work around was to add the Bitfield::fn() member function, which calls the
Bf constructor and returns the constructed instance by value.  This
work-around may be fairly general, if the extra function call layer would
be optimized out in all cases.

Seems like a pretty small change.  I've got a suitcase of Budweiser that I
don't want for anybody who implements this in gcc.

On Tuesday, July 5, 2016 at 11:07:23 PM UTC-4, Louis Dionne wrote:
>
> I think your proposal would be much, much stronger if the only use case
> was not one involving the usage of a macro.
> I'm not saying there aren't other use cases, but simply that you should
> provide them with any hypothetical proposal.
>
> Regards,
> Louis
>
> On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas wrote:
>>
>> This would be useful for macros that take the names of types as
>> parameters.  It would allow the parameter to optionally be a template type
>> parameter.
>>
>> To give a trivial example:
>>
>> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
>> typename CLS::Some_type INSTNAME;
>>
>> The proposed change would allow the macro to be used inside a template
>> definition with a template type parameter as the actual parameter for CLS,
>> as well as in the general case (where CLS is not a formal template
>> parameter).
>>
>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/716c8d93-b35a-4976-a655-76195f0fdb1b%40isocpp.org.

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

<div dir=3D"ltr">Unfortunately, I don&#39;t think there are any use cases t=
hat don&#39;t involve a macro.<div><br></div><div>I ran into this issue in =
this code:</div><div><br></div><div>https://github.com/wkaras/C-plus-plus-l=
ibrary-bit-fields<br></div><div><br></div><div>in the testbf.cpp file in th=
e BITF_CAT macro calls starting at line 561. =C2=A0BITF_CAT (defined in bit=
field.h) originally directly constructed a Bwf::Bf instance. =C2=A0But this=
 did not work here since Bf was a dependant name. =C2=A0My work around was =
to add the Bitfield::fn() member function, which calls the Bf constructor a=
nd returns the constructed instance by value. =C2=A0This work-around may be=
 fairly general, if the extra function call layer would be optimized out in=
 all cases.</div><div><br></div><div>Seems like a pretty small change. =C2=
=A0I&#39;ve got a suitcase of Budweiser that I don&#39;t want for anybody w=
ho implements this in gcc.</div><br>On Tuesday, July 5, 2016 at 11:07:23 PM=
 UTC-4, Louis Dionne wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr">I think your proposal would be much, much stronger if the onl=
y use case was not one involving the usage of a macro.<div>I&#39;m not sayi=
ng there aren&#39;t other use cases, but simply that you should provide the=
m with any hypothetical proposal.</div><div><div><br></div><div>Regards,</d=
iv><div>Louis<br><br>On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This would be =
useful for macros that take the names of types as parameters. =C2=A0It woul=
d allow the parameter to optionally be a template type parameter.<div><br><=
/div><div>To give a trivial example:</div><div><br></div><div>#define INST_=
MBR_SOME_TYPE(CLS, INSTNAME) \</div><div>typename CLS::Some_type INSTNAME;<=
/div><div><br></div><div>The proposed change would allow the macro to be us=
ed inside a template definition with a template type parameter as the actua=
l parameter for CLS, as well as in the general case (where CLS is not a for=
mal template parameter).</div></div></blockquote></div></div></div></blockq=
uote></div>

<p></p>

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

------=_Part_13501_1513620347.1467780129786--

------=_Part_13500_2086069358.1467780129777--

.

------=_Part_12833_1831439078.1467782930493
Content-Type: multipart/alternative;
 boundary="----=_Part_12834_339076895.1467782930494"

------=_Part_12834_339076895.1467782930494
Content-Type: text/plain; charset=UTF-8

On Wednesday, July 6, 2016 at 12:42:10 AM UTC-4, Walt Karas wrote:
>
> Unfortunately, I don't think there are any use cases that don't involve a
> macro.
>
> I ran into this issue in this code:
>
> https://github.com/wkaras/C-plus-plus-library-bit-fields
>

>
in the testbf.cpp file in the BITF_CAT macro calls starting at line 561.
>  BITF_CAT (defined in bitfield.h) originally directly constructed a Bwf::Bf
> instance.  But this did not work here since Bf was a dependant name.
>

Was requiring a simple `using othername = typename Bf;` declaration in
`Bwf` not possible for some reason?

Nowadays, using typename for dependent types is semi-rare. We have template
aliases that can handle that for us.


> Seems like a pretty small change.  I've got a suitcase of Budweiser that I
> don't want for anybody who implements this in gcc.
>
> On Tuesday, July 5, 2016 at 11:07:23 PM UTC-4, Louis Dionne wrote:
>>
>> I think your proposal would be much, much stronger if the only use case
>> was not one involving the usage of a macro.
>> I'm not saying there aren't other use cases, but simply that you should
>> provide them with any hypothetical proposal.
>>
>> Regards,
>> Louis
>>
>> On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas wrote:
>>>
>>> This would be useful for macros that take the names of types as
>>> parameters.  It would allow the parameter to optionally be a template type
>>> parameter.
>>>
>>> To give a trivial example:
>>>
>>> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
>>> typename CLS::Some_type INSTNAME;
>>>
>>> The proposed change would allow the macro to be used inside a template
>>> definition with a template type parameter as the actual parameter for CLS,
>>> as well as in the general case (where CLS is not a formal template
>>> parameter).
>>>
>>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5b3e53b8-cb36-4246-a795-115d127eccd6%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, July 6, 2016 at 12:42:10 AM UTC-4, Walt Kara=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Unfor=
tunately, I don&#39;t think there are any use cases that don&#39;t involve =
a macro.<div><br></div><div>I ran into this issue in this code:</div><div><=
br></div><div><a href=3D"https://github.com/wkaras/C-plus-plus-library-bit-=
fields" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-=
plus-library-bit-fields\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_=
ip1k-50c3-j_5nljA&#39;;return true;" onclick=3D"this.href=3D&#39;https://ww=
w.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-libra=
ry-bit-fields\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-=
j_5nljA&#39;;return true;">https://github.com/wkaras/C-<wbr>plus-plus-libra=
ry-bit-fields</a></div></div></blockquote><blockquote style=3D"margin: 0px =
0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex=
;" class=3D"gmail_quote"><div>=C2=A0</div></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>in the testbf.cpp=
 file in the BITF_CAT macro calls starting at line 561. =C2=A0BITF_CAT (def=
ined in bitfield.h) originally directly constructed a Bwf::Bf instance. =C2=
=A0But this did not work here since Bf was a dependant name.</div></div></b=
lockquote><div><br>Was requiring a simple `using othername =3D typename Bf;=
` declaration  in `Bwf` not possible for some reason?<br><br>Nowadays, usin=
g typename for dependent types is semi-rare. We have template aliases that =
can handle that for us.<br>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div></div><div>Seems like a pretty small change.=
 =C2=A0I&#39;ve got a suitcase of Budweiser that I don&#39;t want for anybo=
dy who implements this in gcc.</div><br>On Tuesday, July 5, 2016 at 11:07:2=
3 PM UTC-4, Louis Dionne wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr">I think your proposal would be much, much stronger if the only=
 use case was not one involving the usage of a macro.<div>I&#39;m not sayin=
g there aren&#39;t other use cases, but simply that you should provide them=
 with any hypothetical proposal.</div><div><div><br></div><div>Regards,</di=
v><div>Louis<br><br>On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas  wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">This would be u=
seful for macros that take the names of types as parameters. =C2=A0It would=
 allow the parameter to optionally be a template type parameter.<div><br></=
div><div>To give a trivial example:</div><div><br></div><div>#define INST_M=
BR_SOME_TYPE(CLS, INSTNAME) \</div><div>typename CLS::Some_type INSTNAME;</=
div><div><br></div><div>The proposed change would allow the macro to be use=
d inside a template definition with a template type parameter as the actual=
 parameter for CLS, as well as in the general case (where CLS is not a form=
al template parameter).</div></div></blockquote></div></div></div></blockqu=
ote></div></blockquote></div>

<p></p>

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

------=_Part_12834_339076895.1467782930494--

------=_Part_12833_1831439078.1467782930493--

.

------=_Part_2835_1462462102.1467803289661
Content-Type: multipart/alternative;
 boundary="----=_Part_2836_1522229100.1467803289661"

------=_Part_2836_1522229100.1467803289661
Content-Type: text/plain; charset=UTF-8



On Wednesday, July 6, 2016 at 1:28:50 AM UTC-4, Nicol Bolas wrote:
>
> On Wednesday, July 6, 2016 at 12:42:10 AM UTC-4, Walt Karas wrote:
>>
>> Unfortunately, I don't think there are any use cases that don't involve a
>> macro.
>>
>> I ran into this issue in this code:
>>
>> https://github.com/wkaras/C-plus-plus-library-bit-fields
>>
>
>>
> in the testbf.cpp file in the BITF_CAT macro calls starting at line 561.
>>  BITF_CAT (defined in bitfield.h) originally directly constructed a Bwf::Bf
>> instance.  But this did not work here since Bf was a dependant name.
>>
>
> Was requiring a simple `using othername = typename Bf;` declaration in
> `Bwf` not possible for some reason?
>

I can't see it that this would help with problem.


>
> Nowadays, using typename for dependent types is semi-rare. We have
> template aliases that can handle that for us.
>

Not clear to m how an alias would apply here.


>
>
>> Seems like a pretty small change.  I've got a suitcase of Budweiser that
>> I don't want for anybody who implements this in gcc.
>>
>> On Tuesday, July 5, 2016 at 11:07:23 PM UTC-4, Louis Dionne wrote:
>>>
>>> I think your proposal would be much, much stronger if the only use case
>>> was not one involving the usage of a macro.
>>> I'm not saying there aren't other use cases, but simply that you should
>>> provide them with any hypothetical proposal.
>>>
>>> Regards,
>>> Louis
>>>
>>> On Tuesday, 5 July 2016 08:18:37 UTC-7, Walt Karas wrote:
>>>>
>>>> This would be useful for macros that take the names of types as
>>>> parameters.  It would allow the parameter to optionally be a template type
>>>> parameter.
>>>>
>>>> To give a trivial example:
>>>>
>>>> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
>>>> typename CLS::Some_type INSTNAME;
>>>>
>>>> The proposed change would allow the macro to be used inside a template
>>>> definition with a template type parameter as the actual parameter for CLS,
>>>> as well as in the general case (where CLS is not a formal template
>>>> parameter).
>>>>
>>>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/82771078-d4aa-4761-853b-7ce21e2e58a6%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 6, 2016 at 1:28:50 AM UTC-4, Ni=
col Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">On Wednesday, July 6, 2016 at 12:42:10 AM UTC-4, Walt Karas wrote:<block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Unfortunately, I don&#39=
;t think there are any use cases that don&#39;t involve a macro.<div><br></=
div><div>I ran into this issue in this code:</div><div><br></div><div><a hr=
ef=3D"https://github.com/wkaras/C-plus-plus-library-bit-fields" rel=3D"nofo=
llow" target=3D"_blank" onmousedown=3D"this.href=3D&#39;https://www.google.=
com/url?q\x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fi=
elds\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#=
39;;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgithub.com%2Fwkaras%2FC-plus-plus-library-bit-fields\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGjN1MHxlfN_ip1k-50c3-j_5nljA&#39;;return=
 true;">https://github.com/wkaras/C-<wbr>plus-plus-library-bit-fields</a></=
div></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><d=
iv>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div></div><div>in the testbf.cpp file in the BITF_CAT macro call=
s starting at line 561. =C2=A0BITF_CAT (defined in bitfield.h) originally d=
irectly constructed a Bwf::Bf instance. =C2=A0But this did not work here si=
nce Bf was a dependant name.</div></div></blockquote><div><br>Was requiring=
 a simple `using othername =3D typename Bf;` declaration  in `Bwf` not poss=
ible for some reason?<br></div></div></blockquote><div><br></div><div>I can=
&#39;t see it that this would help with problem.</div><div>=C2=A0</div><blo=
ckquote 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>Nowadays=
, using typename for dependent types is semi-rare. We have template aliases=
 that can handle that for us.<br></div></div></blockquote><div><br></div><d=
iv>Not clear to m how an alias would apply here.</div><div>=C2=A0</div><blo=
ckquote 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>=C2=A0</div>=
<blockquote 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></div><div>Se=
ems like a pretty small change. =C2=A0I&#39;ve got a suitcase of Budweiser =
that I don&#39;t want for anybody who implements this in gcc.</div><br>On T=
uesday, July 5, 2016 at 11:07:23 PM UTC-4, Louis Dionne wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr">I think your proposal would be =
much, much stronger if the only use case was not one involving the usage of=
 a macro.<div>I&#39;m not saying there aren&#39;t other use cases, but simp=
ly that you should provide them with any hypothetical proposal.</div><div><=
div><br></div><div>Regards,</div><div>Louis<br><br>On Tuesday, 5 July 2016 =
08:18:37 UTC-7, Walt Karas  wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr">This would be useful for macros that take the names of ty=
pes as parameters. =C2=A0It would allow the parameter to optionally be a te=
mplate type parameter.<div><br></div><div>To give a trivial example:</div><=
div><br></div><div>#define INST_MBR_SOME_TYPE(CLS, INSTNAME) \</div><div>ty=
pename CLS::Some_type INSTNAME;</div><div><br></div><div>The proposed chang=
e would allow the macro to be used inside a template definition with a temp=
late type parameter as the actual parameter for CLS, as well as in the gene=
ral case (where CLS is not a formal template parameter).</div></div></block=
quote></div></div></div></blockquote></div></blockquote></div></blockquote>=
</div>

<p></p>

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

------=_Part_2836_1522229100.1467803289661--

------=_Part_2835_1462462102.1467803289661--

.

------=_Part_1074_1609423872.1467847932442
Content-Type: multipart/alternative;
 boundary="----=_Part_1075_269542907.1467847932443"

------=_Part_1075_269542907.1467847932443
Content-Type: text/plain; charset=UTF-8



On Tuesday, July 5, 2016 at 11:18:37 AM UTC-4, Walt Karas wrote:
>
> This would be useful for macros that take the names of types as
> parameters.  It would allow the parameter to optionally be a template type
> parameter.
>
> To give a trivial example:
>
> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
> typename CLS::Some_type INSTNAME;
>
> The proposed change would allow the macro to be used inside a template
> definition with a template type parameter as the actual parameter for CLS,
> as well as in the general case (where CLS is not a formal template
> parameter).
>

Does it not work today?

#include <vector>
typename std::template vector<int> meow;

GCC 4.8+ and Clang 3.0+ accept this already.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2734119c-c3a5-4f85-829b-cc0ac87c1261%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Tuesday, July 5, 2016 at 11:18:37 AM UTC-4, Wal=
t Karas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>This would be useful for macros that take the names of types as parameters=
.. =C2=A0It would allow the parameter to optionally be a template type param=
eter.<div><br></div><div>To give a trivial example:</div><div><br></div><di=
v>#define INST_MBR_SOME_TYPE(CLS, INSTNAME) \</div><div>typename CLS::Some_=
type INSTNAME;</div><div><br></div><div>The proposed change would allow the=
 macro to be used inside a template definition with a template type paramet=
er as the actual parameter for CLS, as well as in the general case (where C=
LS is not a formal template parameter).</div></div></blockquote><div><br></=
div><div>Does it not work today?</div><div><br></div><div class=3D"prettypr=
int" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; =
background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cla=
ss=3D"subprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">#include</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;ve=
ctor&gt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">template</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> vector</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> meow</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span></div></code></div><div><br></div=
><div>GCC 4.8+ and Clang 3.0+ accept this already.</div></div>

<p></p>

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

------=_Part_1075_269542907.1467847932443--

------=_Part_1074_1609423872.1467847932442--

.

------=_Part_5816_1704055585.1467855469314
Content-Type: multipart/alternative;
 boundary="----=_Part_5817_493902194.1467855469314"

------=_Part_5817_493902194.1467855469314
Content-Type: text/plain; charset=UTF-8

Yes looking at n3797, it's slightly ambiguous, but it seems like what I
want is actually already in the standard.  Thanks!

On Wednesday, July 6, 2016 at 7:32:12 PM UTC-4, T. C. wrote:
>
>
>
> On Tuesday, July 5, 2016 at 11:18:37 AM UTC-4, Walt Karas wrote:
>>
>> This would be useful for macros that take the names of types as
>> parameters.  It would allow the parameter to optionally be a template type
>> parameter.
>>
>> To give a trivial example:
>>
>> #define INST_MBR_SOME_TYPE(CLS, INSTNAME) \
>> typename CLS::Some_type INSTNAME;
>>
>> The proposed change would allow the macro to be used inside a template
>> definition with a template type parameter as the actual parameter for CLS,
>> as well as in the general case (where CLS is not a formal template
>> parameter).
>>
>
> Does it not work today?
>
> #include <vector>
> typename std::template vector<int> meow;
>
> GCC 4.8+ and Clang 3.0+ accept this already.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/db8253e1-95fd-43bf-ac4f-212ef6a01729%40isocpp.org.

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

<div dir=3D"ltr">Yes looking at=C2=A0n3797, it&#39;s slightly ambiguous, bu=
t it seems like what I want is actually already in the standard. =C2=A0Than=
ks!<br><br>On Wednesday, July 6, 2016 at 7:32:12 PM UTC-4, T. C. wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Tuesda=
y, July 5, 2016 at 11:18:37 AM UTC-4, Walt Karas wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr">This would be useful for macros that t=
ake the names of types as parameters. =C2=A0It would allow the parameter to=
 optionally be a template type parameter.<div><br></div><div>To give a triv=
ial example:</div><div><br></div><div>#define INST_MBR_SOME_TYPE(CLS, INSTN=
AME) \</div><div>typename CLS::Some_type INSTNAME;</div><div><br></div><div=
>The proposed change would allow the macro to be used inside a template def=
inition with a template type parameter as the actual parameter for CLS, as =
well as in the general case (where CLS is not a formal template parameter).=
</div></div></blockquote><div><br></div><div>Does it not work today?</div><=
div><br></div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:bre=
ak-word;background-color:rgb(250,250,250)"><code><div><span style=3D"color:=
#800">#include</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#080">&lt;vector&gt;</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#008">typename</span><span style=3D"color:#000"> std</span><sp=
an style=3D"color:#660">::</span><span style=3D"color:#008">template</span>=
<span style=3D"color:#000"> vector</span><span style=3D"color:#080">&lt;int=
&gt;</span><span style=3D"color:#000"> meow</span><span style=3D"color:#660=
">;</span><span style=3D"color:#000"> </span></div></code></div><div><br></=
div><div>GCC 4.8+ and Clang 3.0+ accept this already.</div></div></blockquo=
te></div>

<p></p>

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

------=_Part_5817_493902194.1467855469314--

------=_Part_5816_1704055585.1467855469314--

.