------=_Part_275_17891816.1394916381800
Content-Type: text/plain; charset=UTF-8

Is the following supposed to be ill-formed according to the current draft?

template<class> constexpr auto X = 42;
int main(){
        static_assert(X<int> == 42, "");}


[dcl.spec.auto]/4 says that auto is allowed when declaring variables in
namespace-scope, but doesn't explicitly say in variable templates -
consequently this is ill-formed.

Clang trunk rejects it, albeit it with an obtuse error message: "invalid
operands to binary expression ('auto' and 'int')"

Was this intended?

If so, what was the problem with having them?  auto variable templates
would be very useful.

--

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

<div dir=3D"ltr">Is the following supposed to be ill-formed according to th=
e current draft?<div><br></div><div><pre class=3D"lang-cpp prettyprint pret=
typrinted" style=3D"margin-bottom: 10px; padding: 5px; font-size: 14px; fon=
t-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'De=
jaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospace, seri=
f; overflow: auto; width: auto; max-height: 600px; word-wrap: normal; color=
: rgb(0, 0, 0); line-height: 17.804800033569336px; background: rgb(238, 238=
, 238);"><code style=3D"font-family: Consolas, Menlo, Monaco, 'Lucida Conso=
le', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Co=
urier New', monospace, serif; white-space: inherit; background-image: initi=
al; background-attachment: initial; background-size: initial; background-or=
igin: initial; background-clip: initial; background-position: initial; back=
ground-repeat: initial;"><span class=3D"kwd" style=3D"color: rgb(0, 0, 139)=
; background: transparent;">template</span><span class=3D"str" style=3D"col=
or: rgb(128, 0, 0); background: transparent;">&lt;class&gt;</span><span cla=
ss=3D"pln" style=3D"background: transparent;"> </span><span class=3D"kwd" s=
tyle=3D"color: rgb(0, 0, 139); background: transparent;">constexpr</span><s=
pan class=3D"pln" style=3D"background: transparent;"> </span><span class=3D=
"kwd" style=3D"color: rgb(0, 0, 139); background: transparent;">auto</span>=
<span class=3D"pln" style=3D"background: transparent;"> X </span><span clas=
s=3D"pun" style=3D"background: transparent;">=3D</span><span class=3D"pln" =
style=3D"background: transparent;"> </span><span class=3D"lit" style=3D"col=
or: rgb(128, 0, 0); background: transparent;">42</span><span class=3D"pun" =
style=3D"background: transparent;">;</span><span class=3D"pln" style=3D"bac=
kground: transparent;">

</span><span class=3D"typ" style=3D"color: rgb(43, 145, 175); background: t=
ransparent;">int</span><span class=3D"pln" style=3D"background: transparent=
;"> main</span><span class=3D"pun" style=3D"background: transparent;">()</s=
pan><span class=3D"pln" style=3D"background: transparent;">
</span><span class=3D"pun" style=3D"background: transparent;">{</span><span=
 class=3D"pln" style=3D"background: transparent;">
        </span><span class=3D"kwd" style=3D"color: rgb(0, 0, 139); backgrou=
nd: transparent;">static_assert</span><span class=3D"pun" style=3D"backgrou=
nd: transparent;">(</span><span class=3D"pln" style=3D"background: transpar=
ent;">X</span><span class=3D"str" style=3D"color: rgb(128, 0, 0); backgroun=
d: transparent;">&lt;int&gt;</span><span class=3D"pln" style=3D"background:=
 transparent;"> </span><span class=3D"pun" style=3D"background: transparent=
;">=3D=3D</span><span class=3D"pln" style=3D"background: transparent;"> </s=
pan><span class=3D"lit" style=3D"color: rgb(128, 0, 0); background: transpa=
rent;">42</span><span class=3D"pun" style=3D"background: transparent;">,</s=
pan><span class=3D"pln" style=3D"background: transparent;"> </span><span cl=
ass=3D"str" style=3D"color: rgb(128, 0, 0); background: transparent;">""</s=
pan><span class=3D"pun" style=3D"background: transparent;">);</span><span c=
lass=3D"pln" style=3D"background: transparent;">
</span><span class=3D"pun" style=3D"background: transparent;">}</span></cod=
e></pre></div><div><br></div><div>[dcl.spec.auto]/4 says that auto is allow=
ed when declaring variables in namespace-scope, but doesn't explicitly say =
in variable templates - consequently this is ill-formed.</div><div><br></di=
v><div>Clang trunk rejects it, albeit it with an obtuse error message: "<sp=
an class=3D"pln" style=3D"font-family: Consolas, Menlo, Monaco, 'Lucida Con=
sole', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', '=
Courier New', monospace, serif; white-space: inherit; color: rgb(0, 0, 0); =
font-size: 14px; line-height: 17.804800033569336px; background: transparent=
;">invalid operands to binary expression </span><span class=3D"pun" style=
=3D"font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mon=
o', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospac=
e, serif; white-space: inherit; color: rgb(0, 0, 0); font-size: 14px; line-=
height: 17.804800033569336px; background: transparent;">(</span><span class=
=3D"str" style=3D"font-family: Consolas, Menlo, Monaco, 'Lucida Console', '=
Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier =
New', monospace, serif; white-space: inherit; font-size: 14px; line-height:=
 17.804800033569336px; color: rgb(128, 0, 0); background: transparent;">'au=
to'</span><span class=3D"pln" style=3D"font-family: Consolas, Menlo, Monaco=
, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono', 'Bitstream Vera =
Sans Mono', 'Courier New', monospace, serif; white-space: inherit; color: r=
gb(0, 0, 0); font-size: 14px; line-height: 17.804800033569336px; background=
: transparent;"> and </span><span class=3D"str" style=3D"font-family: Conso=
las, Menlo, Monaco, 'Lucida Console', 'Liberation Mono', 'DejaVu Sans Mono'=
, 'Bitstream Vera Sans Mono', 'Courier New', monospace, serif; white-space:=
 inherit; font-size: 14px; line-height: 17.804800033569336px; color: rgb(12=
8, 0, 0); background: transparent;">'int'</span><span class=3D"pun" style=
=3D"font-family: Consolas, Menlo, Monaco, 'Lucida Console', 'Liberation Mon=
o', 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Courier New', monospac=
e, serif; white-space: inherit; color: rgb(0, 0, 0); font-size: 14px; line-=
height: 17.804800033569336px; background: transparent;">)"</span></div><div=
><br></div><div>Was this intended?</div><div><br></div><div>If so, what was=
 the problem with having them? &nbsp;auto variable templates would be very =
useful.</div><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 />

------=_Part_275_17891816.1394916381800--

.

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

On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:

> Is the following supposed to be ill-formed according to the current draft?
>
> template<class> constexpr auto X = 42;
> int main(){
>         static_assert(X<int> == 42, "");}
>
>
> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
> namespace-scope, but doesn't explicitly say in variable templates -
> consequently this is ill-formed.
>

A specialization of a variable template is a variable, so this is allowed.


> Clang trunk rejects it, albeit it with an obtuse error message: "invalid
> operands to binary expression ('auto' and 'int')"
>
> Was this intended?
>

Looks like a bug.

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 15, 2014 at 1:46 PM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=
=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Is the following supposed t=
o be ill-formed according to the current draft?<div><br></div><div><pre sty=
le=3D"line-height:17.804800033569336px;max-height:600px;background:rgb(238,=
238,238);width:auto;overflow:auto;font-size:14px;margin-bottom:10px;font-fa=
mily:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#3=
9;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Couri=
er New&#39;,monospace,serif;word-wrap:normal;padding:5px">
<code style=3D"font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&=
#39;Liberation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera San=
s Mono&#39;,&#39;Courier New&#39;,monospace,serif;white-space:inherit;backg=
round-image:initial;background-repeat:initial"><span style=3D"color:rgb(0,0=
,139);background:transparent">template</span><span style=3D"color:rgb(128,0=
,0);background:transparent">&lt;class&gt;</span><span style=3D"background:t=
ransparent"> </span><span style=3D"color:rgb(0,0,139);background:transparen=
t">constexpr</span><span style=3D"background:transparent"> </span><span sty=
le=3D"color:rgb(0,0,139);background:transparent">auto</span><span style=3D"=
background:transparent"> X </span><span style=3D"background:transparent">=
=3D</span><span style=3D"background:transparent"> </span><span style=3D"col=
or:rgb(128,0,0);background:transparent">42</span><span style=3D"background:=
transparent">;</span><span style=3D"background:transparent">

</span><span style=3D"color:rgb(43,145,175);background:transparent">int</sp=
an><span style=3D"background:transparent"> main</span><span style=3D"backgr=
ound:transparent">()</span><span style=3D"background:transparent">
</span><span style=3D"background:transparent">{</span><span style=3D"backgr=
ound:transparent">
        </span><span style=3D"color:rgb(0,0,139);background:transparent">st=
atic_assert</span><span style=3D"background:transparent">(</span><span styl=
e=3D"background:transparent">X</span><span style=3D"color:rgb(128,0,0);back=
ground:transparent">&lt;int&gt;</span><span style=3D"background:transparent=
"> </span><span style=3D"background:transparent">=3D=3D</span><span style=
=3D"background:transparent"> </span><span style=3D"color:rgb(128,0,0);backg=
round:transparent">42</span><span style=3D"background:transparent">,</span>=
<span style=3D"background:transparent"> </span><span style=3D"color:rgb(128=
,0,0);background:transparent">&quot;&quot;</span><span style=3D"background:=
transparent">);</span><span style=3D"background:transparent">
</span><span style=3D"background:transparent">}</span></code></pre></div><d=
iv><br></div><div>[dcl.spec.auto]/4 says that auto is allowed when declarin=
g variables in namespace-scope, but doesn&#39;t explicitly say in variable =
templates - consequently this is ill-formed.</div>
</div></blockquote><div><br></div><div>A specialization of a variable templ=
ate is a variable, so this is allowed.</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div>Clang trunk rejects it, albeit it with an obtuse erro=
r message: &quot;<span style=3D"line-height:17.804800033569336px;background=
:transparent;font-size:14px;white-space:inherit;font-family:Consolas,Menlo,=
Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#39;,&#39;DejaVu Sans =
Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Courier New&#39;,monospac=
e,serif">invalid operands to binary expression </span><span style=3D"line-h=
eight:17.804800033569336px;background:transparent;font-size:14px;white-spac=
e:inherit;font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;L=
iberation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mon=
o&#39;,&#39;Courier New&#39;,monospace,serif">(</span><span style=3D"font-f=
amily:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#=
39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Cour=
ier New&#39;,monospace,serif;white-space:inherit;font-size:14px;line-height=
:17.804800033569336px;color:rgb(128,0,0);background:transparent">&#39;auto&=
#39;</span><span style=3D"line-height:17.804800033569336px;background:trans=
parent;font-size:14px;white-space:inherit;font-family:Consolas,Menlo,Monaco=
,&#39;Lucida Console&#39;,&#39;Liberation Mono&#39;,&#39;DejaVu Sans Mono&#=
39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Courier New&#39;,monospace,seri=
f"> and </span><span style=3D"font-family:Consolas,Menlo,Monaco,&#39;Lucida=
 Console&#39;,&#39;Liberation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bit=
stream Vera Sans Mono&#39;,&#39;Courier New&#39;,monospace,serif;white-spac=
e:inherit;font-size:14px;line-height:17.804800033569336px;color:rgb(128,0,0=
);background:transparent">&#39;int&#39;</span><span style=3D"line-height:17=
..804800033569336px;background:transparent;font-size:14px;white-space:inheri=
t;font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberatio=
n Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&=
#39;Courier New&#39;,monospace,serif">)&quot;</span></div>
<div><br></div><div>Was this intended?</div></div></blockquote><div><br></d=
iv><div>Looks like a bug.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c1d71ce9ba4a04f4adaf8d--

.

2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>>
>> Is the following supposed to be ill-formed according to the current draft?
>>
>> template<class> constexpr auto X = 42;
>>
>> int main()
>> {
>>         static_assert(X<int> == 42, "");
>> }
>>
>>
>> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
>> namespace-scope, but doesn't explicitly say in variable templates -
>> consequently this is ill-formed.
>
>
> A specialization of a variable template is a variable, so this is allowed.
>

I don't understand this reason. The following is not a specialization
of a variable template, is it?

   template<class> constexpr auto X = 42;

The Standard says in 7.1.6.4p6, "A program that uses auto or
decltype(auto) in a context not explicitly allowed in this section is
ill-formed."

The section does not explicitly allow "auto" for variable templates.
Why does it matter that the specialization of that template is a
variable?

--

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

.

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

On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos <andrewtomazos@gmail.com
> >
> > wrote:
> >>
> >> Is the following supposed to be ill-formed according to the current
> draft?
> >>
> >> template<class> constexpr auto X = 42;
> >>
> >> int main()
> >> {
> >>         static_assert(X<int> == 42, "");
> >> }
> >>
> >>
> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
> >> namespace-scope, but doesn't explicitly say in variable templates -
> >> consequently this is ill-formed.
> >
> >
> > A specialization of a variable template is a variable, so this is
> allowed.
> >
>
> I don't understand this reason. The following is not a specialization
> of a variable template, is it?
>
>    template<class> constexpr auto X = 42;
>
> The Standard says in 7.1.6.4p6, "A program that uses auto or
> decltype(auto) in a context not explicitly allowed in this section is
> ill-formed."
>
> The section does not explicitly allow "auto" for variable templates.
> Why does it matter that the specialization of that template is a
> variable?


Because the validity of a template isn't governed by the usual language
rules. 14.6/8: "No diagnostic shall be issued for a template for which a
valid specialization can be generated."

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 15, 2014 at 5:13 PM, Johannes Schaub <span dir=3D"ltr">&lt;<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-03-16 0:38 GMT+01:00 Richard Smith &lt;=
<a href=3D"mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt;:<br>
<div class=3D"">&gt; On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos &lt;<a=
 href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>&gt;<br=
>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Is the following supposed to be ill-formed according to the curren=
t draft?<br>
&gt;&gt;<br>
&gt;&gt; template&lt;class&gt; constexpr auto X =3D 42;<br>
&gt;&gt;<br>
&gt;&gt; int main()<br>
&gt;&gt; {<br>
&gt;&gt; =A0 =A0 =A0 =A0 static_assert(X&lt;int&gt; =3D=3D 42, &quot;&quot;=
);<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; [dcl.spec.auto]/4 says that auto is allowed when declaring variabl=
es in<br>
&gt;&gt; namespace-scope, but doesn&#39;t explicitly say in variable templa=
tes -<br>
&gt;&gt; consequently this is ill-formed.<br>
&gt;<br>
&gt;<br>
&gt; A specialization of a variable template is a variable, so this is allo=
wed.<br>
&gt;<br>
<br>
</div>I don&#39;t understand this reason. The following is not a specializa=
tion<br>
of a variable template, is it?<br>
<div class=3D""><br>
=A0 =A0template&lt;class&gt; constexpr auto X =3D 42;<br>
<br>
</div>The Standard says in 7.1.6.4p6, &quot;A program that uses auto or<br>
decltype(auto) in a context not explicitly allowed in this section is<br>
ill-formed.&quot;<br>
<br>
The section does not explicitly allow &quot;auto&quot; for variable templat=
es.<br>
Why does it matter that the specialization of that template is a<br>
variable?</blockquote><div><br></div><div>Because the validity of a templat=
e isn&#39;t governed by the usual language rules. 14.6/8: &quot;No diagnost=
ic shall be issued for a template for which a valid specialization can be g=
enerated.&quot;</div>
</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d84ef2b25a604f4ae3a2a--

.

2014-03-16 1:17 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub
> <schaub.johannes@googlemail.com> wrote:
>>
>> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
>> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
>> > <andrewtomazos@gmail.com>
>> > wrote:
>> >>
>> >> Is the following supposed to be ill-formed according to the current
>> >> draft?
>> >>
>> >> template<class> constexpr auto X = 42;
>> >>
>> >> int main()
>> >> {
>> >>         static_assert(X<int> == 42, "");
>> >> }
>> >>
>> >>
>> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
>> >> namespace-scope, but doesn't explicitly say in variable templates -
>> >> consequently this is ill-formed.
>> >
>> >
>> > A specialization of a variable template is a variable, so this is
>> > allowed.
>> >
>>
>> I don't understand this reason. The following is not a specialization
>> of a variable template, is it?
>>
>>    template<class> constexpr auto X = 42;
>>
>> The Standard says in 7.1.6.4p6, "A program that uses auto or
>> decltype(auto) in a context not explicitly allowed in this section is
>> ill-formed."
>>
>> The section does not explicitly allow "auto" for variable templates.
>> Why does it matter that the specialization of that template is a
>> variable?
>
>
> Because the validity of a template isn't governed by the usual language
> rules. 14.6/8: "No diagnostic shall be issued for a template for which a
> valid specialization can be generated."
>

Thanks, I have never interpreted this sentence in that way. It just
sounds to me as a warning to prematurely rejecting compilers. IMO a
much better way to word this would be along the way of

   "A template that is made ill-formed by a rule not in this paragraph
is still well-formed as long as a valid specialization can be
generated for it."

As it is stated in the Standard, it sounds like the rule talks about
well-formed templates only.

--

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

.

2014-03-16 1:17 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub
> <schaub.johannes@googlemail.com> wrote:
>>
>> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
>> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
>> > <andrewtomazos@gmail.com>
>> > wrote:
>> >>
>> >> Is the following supposed to be ill-formed according to the current
>> >> draft?
>> >>
>> >> template<class> constexpr auto X = 42;
>> >>
>> >> int main()
>> >> {
>> >>         static_assert(X<int> == 42, "");
>> >> }
>> >>
>> >>
>> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
>> >> namespace-scope, but doesn't explicitly say in variable templates -
>> >> consequently this is ill-formed.
>> >
>> >
>> > A specialization of a variable template is a variable, so this is
>> > allowed.
>> >
>>
>> I don't understand this reason. The following is not a specialization
>> of a variable template, is it?
>>
>>    template<class> constexpr auto X = 42;
>>
>> The Standard says in 7.1.6.4p6, "A program that uses auto or
>> decltype(auto) in a context not explicitly allowed in this section is
>> ill-formed."
>>
>> The section does not explicitly allow "auto" for variable templates.
>> Why does it matter that the specialization of that template is a
>> variable?
>
>
> Because the validity of a template isn't governed by the usual language
> rules. 14.6/8: "No diagnostic shall be issued for a template for which a
> valid specialization can be generated."
>

It's also not clear to me where to draw the line. Consider

class Y {
  typedef int type;
};

template<Y::type N>
struct X { };

The specialization of this template does not have template parameters,
since it's a normal class. A diangostic should therefor not be
generated for the class template, since the specialization is valid.
However, clang complains

"main.cpp:5:13: error: 'type' is a private member of 'Y'"

--

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

.

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

On Sat, Mar 15, 2014 at 4:38 PM, Richard Smith <richard@metafoo.co.uk>wrote:

> On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
>
>> Is the following supposed to be ill-formed according to the current draft?
>>
>> template<class> constexpr auto X = 42;
>> int main(){
>>         static_assert(X<int> == 42, "");}
>>
>>
>> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
>> namespace-scope, but doesn't explicitly say in variable templates -
>> consequently this is ill-formed.
>>
>
> A specialization of a variable template is a variable, so this is allowed.
>
>
>> Clang trunk rejects it, albeit it with an obtuse error message: "invalid
>> operands to binary expression ('auto' and 'int')"
>>
>> Was this intended?
>>
>
> Looks like a bug.
>

(Now fixed in Clang trunk.)

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Mar 15, 2014 at 4:38 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"">On Sat, Mar 15, 2014 at 1:46 PM,=
 Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail=
..com" target=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Is the following supposed t=
o be ill-formed according to the current draft?<div><br></div><div><pre sty=
le=3D"line-height:17.804800033569336px;max-height:600px;background:rgb(238,=
238,238);width:auto;overflow:auto;font-size:14px;margin-bottom:10px;font-fa=
mily:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#3=
9;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Couri=
er New&#39;,monospace,serif;word-wrap:normal;padding:5px">
<code style=3D"font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&=
#39;Liberation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera San=
s Mono&#39;,&#39;Courier New&#39;,monospace,serif;white-space:inherit;backg=
round-image:initial;background-repeat:initial"><span style=3D"color:rgb(0,0=
,139);background:transparent">template</span><span style=3D"color:rgb(128,0=
,0);background:transparent">&lt;class&gt;</span><span style=3D"background:t=
ransparent"> </span><span style=3D"color:rgb(0,0,139);background:transparen=
t">constexpr</span><span style=3D"background:transparent"> </span><span sty=
le=3D"color:rgb(0,0,139);background:transparent">auto</span><span style=3D"=
background:transparent"> X </span><span style=3D"background:transparent">=
=3D</span><span style=3D"background:transparent"> </span><span style=3D"col=
or:rgb(128,0,0);background:transparent">42</span><span style=3D"background:=
transparent">;</span><span style=3D"background:transparent">

</span><span style=3D"color:rgb(43,145,175);background:transparent">int</sp=
an><span style=3D"background:transparent"> main</span><span style=3D"backgr=
ound:transparent">()</span><span style=3D"background:transparent">
</span><span style=3D"background:transparent">{</span><span style=3D"backgr=
ound:transparent">
        </span><span style=3D"color:rgb(0,0,139);background:transparent">st=
atic_assert</span><span style=3D"background:transparent">(</span><span styl=
e=3D"background:transparent">X</span><span style=3D"color:rgb(128,0,0);back=
ground:transparent">&lt;int&gt;</span><span style=3D"background:transparent=
"> </span><span style=3D"background:transparent">=3D=3D</span><span style=
=3D"background:transparent"> </span><span style=3D"color:rgb(128,0,0);backg=
round:transparent">42</span><span style=3D"background:transparent">,</span>=
<span style=3D"background:transparent"> </span><span style=3D"color:rgb(128=
,0,0);background:transparent">&quot;&quot;</span><span style=3D"background:=
transparent">);</span><span style=3D"background:transparent">
</span><span style=3D"background:transparent">}</span></code></pre></div><d=
iv><br></div><div>[dcl.spec.auto]/4 says that auto is allowed when declarin=
g variables in namespace-scope, but doesn&#39;t explicitly say in variable =
templates - consequently this is ill-formed.</div>

</div></blockquote><div><br></div></div><div>A specialization of a variable=
 template is a variable, so this is allowed.</div><div class=3D""><div>=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">

<div dir=3D"ltr"><div>Clang trunk rejects it, albeit it with an obtuse erro=
r message: &quot;<span style=3D"line-height:17.804800033569336px;background=
:transparent;font-size:14px;white-space:inherit;font-family:Consolas,Menlo,=
Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#39;,&#39;DejaVu Sans =
Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Courier New&#39;,monospac=
e,serif">invalid operands to binary expression </span><span style=3D"line-h=
eight:17.804800033569336px;background:transparent;font-size:14px;white-spac=
e:inherit;font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;L=
iberation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mon=
o&#39;,&#39;Courier New&#39;,monospace,serif">(</span><span style=3D"font-f=
amily:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberation Mono&#=
39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Cour=
ier New&#39;,monospace,serif;white-space:inherit;font-size:14px;line-height=
:17.804800033569336px;color:rgb(128,0,0);background:transparent">&#39;auto&=
#39;</span><span style=3D"line-height:17.804800033569336px;background:trans=
parent;font-size:14px;white-space:inherit;font-family:Consolas,Menlo,Monaco=
,&#39;Lucida Console&#39;,&#39;Liberation Mono&#39;,&#39;DejaVu Sans Mono&#=
39;,&#39;Bitstream Vera Sans Mono&#39;,&#39;Courier New&#39;,monospace,seri=
f"> and </span><span style=3D"font-family:Consolas,Menlo,Monaco,&#39;Lucida=
 Console&#39;,&#39;Liberation Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bit=
stream Vera Sans Mono&#39;,&#39;Courier New&#39;,monospace,serif;white-spac=
e:inherit;font-size:14px;line-height:17.804800033569336px;color:rgb(128,0,0=
);background:transparent">&#39;int&#39;</span><span style=3D"line-height:17=
..804800033569336px;background:transparent;font-size:14px;white-space:inheri=
t;font-family:Consolas,Menlo,Monaco,&#39;Lucida Console&#39;,&#39;Liberatio=
n Mono&#39;,&#39;DejaVu Sans Mono&#39;,&#39;Bitstream Vera Sans Mono&#39;,&=
#39;Courier New&#39;,monospace,serif">)&quot;</span></div>

<div><br></div><div>Was this intended?</div></div></blockquote><div><br></d=
iv></div><div>Looks like a bug.</div></div></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">(Now fixed in Clang=
 trunk.)</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 />

--001a11c2ca0c9fcc5104f4aeed98--

.

Richard Smith <richard@metafoo.co.uk> writes:

| On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
| <andrewtomazos@gmail.com> wrote:
|
|     Is the following supposed to be ill-formed according to the
|     current draft?
|
|
|
|
| template<class> constexpr auto X = 42;
|
| int main()
| {
|         static_assert(X<int> == 42, "");
| }
|
|
|     [dcl.spec.auto]/4 says that auto is allowed when declaring
|     variables in namespace-scope, but doesn't explicitly say in
|     variable templates - consequently this is ill-formed.
|
|
| A specialization of a variable template is a variable, so this is
| allowed.

Indeed.

-- Gaby

--

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

.

Johannes Schaub <schaub.johannes@googlemail.com> writes:

| 2014-03-16 1:17 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
| > On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub
| > <schaub.johannes@googlemail.com> wrote:
| >>
| >> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
| >> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
| >> > <andrewtomazos@gmail.com>
| >> > wrote:
| >> >>
| >> >> Is the following supposed to be ill-formed according to the current
| >> >> draft?
| >> >>
| >> >> template<class> constexpr auto X = 42;
| >> >>
| >> >> int main()
| >> >> {
| >> >>         static_assert(X<int> == 42, "");
| >> >> }
| >> >>
| >> >>
| >> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
| >> >> namespace-scope, but doesn't explicitly say in variable templates -
| >> >> consequently this is ill-formed.
| >> >
| >> >
| >> > A specialization of a variable template is a variable, so this is
| >> > allowed.
| >> >
| >>
| >> I don't understand this reason. The following is not a specialization
| >> of a variable template, is it?
| >>
| >>    template<class> constexpr auto X = 42;
| >>
| >> The Standard says in 7.1.6.4p6, "A program that uses auto or
| >> decltype(auto) in a context not explicitly allowed in this section is
| >> ill-formed."
| >>
| >> The section does not explicitly allow "auto" for variable templates.
| >> Why does it matter that the specialization of that template is a
| >> variable?
| >
| >
| > Because the validity of a template isn't governed by the usual language
| > rules. 14.6/8: "No diagnostic shall be issued for a template for which a
| > valid specialization can be generated."
| >
|
| Thanks, I have never interpreted this sentence in that way. It just
| sounds to me as a warning to prematurely rejecting compilers. IMO a
| much better way to word this would be along the way of
|
|    "A template that is made ill-formed by a rule not in this paragraph
| is still well-formed as long as a valid specialization can be
| generated for it."
|
| As it is stated in the Standard, it sounds like the rule talks about
| well-formed templates only.


The general model of C++ templates, since day 1, is that if decl is a
valid declaration, then

   template <parameter-list> decl

is also a valid declaration.  There are a few exceptions (like you can't
have a non-static data member templates or virtual function templats),
but that is basically it.

Inverting that principle gives a "formal" rule that Richard pointed out
in his previous message, although tha rules cover more grounds.

-- Gaby

--

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

.

Johannes Schaub <schaub.johannes@googlemail.com> writes:

| 2014-03-16 1:17 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
| > On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub
| > <schaub.johannes@googlemail.com> wrote:
| >>
| >> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
| >> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
| >> > <andrewtomazos@gmail.com>
| >> > wrote:
| >> >>
| >> >> Is the following supposed to be ill-formed according to the current
| >> >> draft?
| >> >>
| >> >> template<class> constexpr auto X = 42;
| >> >>
| >> >> int main()
| >> >> {
| >> >>         static_assert(X<int> == 42, "");
| >> >> }
| >> >>
| >> >>
| >> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
| >> >> namespace-scope, but doesn't explicitly say in variable templates -
| >> >> consequently this is ill-formed.
| >> >
| >> >
| >> > A specialization of a variable template is a variable, so this is
| >> > allowed.
| >> >
| >>
| >> I don't understand this reason. The following is not a specialization
| >> of a variable template, is it?
| >>
| >>    template<class> constexpr auto X = 42;
| >>
| >> The Standard says in 7.1.6.4p6, "A program that uses auto or
| >> decltype(auto) in a context not explicitly allowed in this section is
| >> ill-formed."
| >>
| >> The section does not explicitly allow "auto" for variable templates.
| >> Why does it matter that the specialization of that template is a
| >> variable?
| >
| >
| > Because the validity of a template isn't governed by the usual language
| > rules. 14.6/8: "No diagnostic shall be issued for a template for which a
| > valid specialization can be generated."
| >
|
| It's also not clear to me where to draw the line. Consider
|
| class Y {
|   typedef int type;
| };
|
| template<Y::type N>
| struct X { };
|
| The specialization of this template does not have template parameters,

I don't understand why this particular observation is important.  Could
you elaborate?

| since it's a normal class. A diangostic should therefor not be
| generated for the class template, since the specialization is valid.
| However, clang complains
|
| "main.cpp:5:13: error: 'type' is a private member of 'Y'"

The issue here is different: it is the declaration itself that is invalid
in the sense that the declaration of the template (regardless of whether
it can have a specialization) uses an inaccessible name.

-- Gaby

--

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

.

--Apple-Mail=_1F6E5604-0410-4CF4-BB7A-1C6308A8C33F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-16, at 3:49 PM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:

> The general model of C++ templates, since day 1, is that if decl is a
> valid declaration, then
>=20
>   template <parameter-list> decl
>=20
> is also a valid declaration.

Well, Johannes' code is specifically a counterexample to that rule, because=
 the error is in the parameter-list.

It seems fairly obvious that an invalid template parameter declaration is d=
iagnosed when translating it, not at instantiation. If his code exposes a d=
efect, it belongs to name lookup, not the instantiation process. (Should th=
at name be accessible, if the template had a friend declaration? However it=
 is not a friend in the example.)

His argument, though, seems to be that there is a slippery slope of allowin=
g things that aren't specifically specified. I don't buy it.

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

--Apple-Mail=_1F6E5604-0410-4CF4-BB7A-1C6308A8C33F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03&ndash;16, at 3:49 PM, Gabriel Dos Reis &lt;<a href=3D"mailto:gdr@a=
xiomatics.org">gdr@axiomatics.org</a>&gt; wrote:</div><br class=3D"Apple-in=
terchange-newline"><blockquote type=3D"cite">The general model of C++ templ=
ates, since day 1, is that if decl is a<br>valid declaration, then<br><br> =
&nbsp;&nbsp;template &lt;parameter-list&gt; decl<br><br>is also a valid dec=
laration.</blockquote><div><br></div><div>Well, Johannes&rsquo; code is spe=
cifically a counterexample to that rule, because the error is in the parame=
ter-list.</div><div><br></div><div>It seems fairly obvious that an invalid =
template parameter declaration is diagnosed when translating it, not at ins=
tantiation. If his code exposes a defect, it belongs to name lookup, not th=
e instantiation process. (<i>Should</i>&nbsp;that name be accessible, if th=
e template had a <font face=3D"Courier">friend</font> declaration? However =
it is not a <font face=3D"Courier">friend</font> in the example.)</div></di=
v><div><br></div><div>His argument, though, seems to be that there is a sli=
ppery slope of allowing things that aren&rsquo;t specifically specified. I =
don&rsquo;t buy it.</div><div><br></div></body></html>

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

--Apple-Mail=_1F6E5604-0410-4CF4-BB7A-1C6308A8C33F--

.

------=_Part_4390_24636596.1394969987810
Content-Type: text/plain; charset=UTF-8

is typedef a declaration? I remember VC++ suppporting template typedefs
however apparently this was not standard C++.

Op zaterdag 15 maart 2014 21:46:21 UTC+1 schreef Andrew Tomazos:
>
> Is the following supposed to be ill-formed according to the current draft?
>
> template<class> constexpr auto X = 42;
> int main(){
>         static_assert(X<int> == 42, "");}
>
>
> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
> namespace-scope, but doesn't explicitly say in variable templates -
> consequently this is ill-formed.
>
> Clang trunk rejects it, albeit it with an obtuse error message: "invalid
> operands to binary expression ('auto' and 'int')"
>
> Was this intended?
>
> If so, what was the problem with having them?  auto variable templates
> would be very useful.
>
>

--

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

<div dir=3D"ltr">is typedef a declaration? I remember VC++ suppporting temp=
late typedefs however apparently this was not standard C++.<br><br>Op zater=
dag 15 maart 2014 21:46:21 UTC+1 schreef Andrew Tomazos:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">Is the following supposed to b=
e ill-formed according to the current draft?<div><br></div><div><pre style=
=3D"margin-bottom:10px;padding:5px;font-size:14px;font-family:Consolas,Menl=
o,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bitstream V=
era Sans Mono','Courier New',monospace,serif;overflow:auto;width:auto;max-h=
eight:600px;word-wrap:normal;color:rgb(0,0,0);line-height:17.80480003356933=
6px;background:rgb(238,238,238)"><code style=3D"font-family:Consolas,Menlo,=
Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bitstream Ver=
a Sans Mono','Courier New',monospace,serif;white-space:inherit;background-i=
mage:initial;background-repeat:initial"><span style=3D"color:rgb(0,0,139);b=
ackground:transparent">template</span><span style=3D"color:rgb(128,0,0);bac=
kground:transparent">&lt;class&gt;</span><span style=3D"background:transpar=
ent"> </span><span style=3D"color:rgb(0,0,139);background:transparent">cons=
texpr</span><span style=3D"background:transparent"> </span><span style=3D"c=
olor:rgb(0,0,139);background:transparent">auto</span><span style=3D"backgro=
und:transparent"> X </span><span style=3D"background:transparent">=3D</span=
><span style=3D"background:transparent"> </span><span style=3D"color:rgb(12=
8,0,0);background:transparent">42</span><span style=3D"background:transpare=
nt">;</span><span style=3D"background:transparent">

</span><span style=3D"color:rgb(43,145,175);background:transparent">int</sp=
an><span style=3D"background:transparent"> main</span><span style=3D"backgr=
ound:transparent">()</span><span style=3D"background:transparent">
</span><span style=3D"background:transparent">{</span><span style=3D"backgr=
ound:transparent">
        </span><span style=3D"color:rgb(0,0,139);background:transparent">st=
atic_assert</span><span style=3D"background:transparent">(</span><span styl=
e=3D"background:transparent">X</span><span style=3D"color:rgb(128,0,0);back=
ground:transparent">&lt;int&gt;</span><span style=3D"background:transparent=
"> </span><span style=3D"background:transparent">=3D=3D</span><span style=
=3D"background:transparent"> </span><span style=3D"color:rgb(128,0,0);backg=
round:transparent">42</span><span style=3D"background:transparent">,</span>=
<span style=3D"background:transparent"> </span><span style=3D"color:rgb(128=
,0,0);background:transparent">""</span><span style=3D"background:transparen=
t">);</span><span style=3D"background:transparent">
</span><span style=3D"background:transparent">}</span></code></pre></div><d=
iv><br></div><div>[dcl.spec.auto]/4 says that auto is allowed when declarin=
g variables in namespace-scope, but doesn't explicitly say in variable temp=
lates - consequently this is ill-formed.</div><div><br></div><div>Clang tru=
nk rejects it, albeit it with an obtuse error message: "<span style=3D"font=
-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu Sa=
ns Mono','Bitstream Vera Sans Mono','Courier New',monospace,serif;white-spa=
ce:inherit;color:rgb(0,0,0);font-size:14px;line-height:17.804800033569336px=
;background:transparent">invalid operands to binary expression </span><span=
 style=3D"font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mo=
no','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',monospace,s=
erif;white-space:inherit;color:rgb(0,0,0);font-size:14px;line-height:17.804=
800033569336px;background:transparent">(</span><span style=3D"font-family:C=
onsolas,Menlo,Monaco,'Lucida Console','Liberation Mono','DejaVu Sans Mono',=
'Bitstream Vera Sans Mono','Courier New',monospace,serif;white-space:inheri=
t;font-size:14px;line-height:17.804800033569336px;color:rgb(128,0,0);backgr=
ound:transparent">'auto'</span><span style=3D"font-family:Consolas,Menlo,Mo=
naco,'Lucida Console','Liberation Mono','DejaVu Sans Mono','Bitstream Vera =
Sans Mono','Courier New',monospace,serif;white-space:inherit;color:rgb(0,0,=
0);font-size:14px;line-height:17.804800033569336px;background:transparent">=
 and </span><span style=3D"font-family:Consolas,Menlo,Monaco,'Lucida Consol=
e','Liberation Mono','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier=
 New',monospace,serif;white-space:inherit;font-size:14px;line-height:17.804=
800033569336px;color:rgb(128,0,0);background:transparent">'int'</span><span=
 style=3D"font-family:Consolas,Menlo,Monaco,'Lucida Console','Liberation Mo=
no','DejaVu Sans Mono','Bitstream Vera Sans Mono','Courier New',monospace,s=
erif;white-space:inherit;color:rgb(0,0,0);font-size:14px;line-height:17.804=
800033569336px;background:transparent">)"</span></div><div><br></div><div>W=
as this intended?</div><div><br></div><div>If so, what was the problem with=
 having them? &nbsp;auto variable templates would be very useful.</div><div=
><br></div></div></blockquote></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_4390_24636596.1394969987810--

.

2014-03-16 8:53 GMT+01:00 Gabriel Dos Reis <gdr@axiomatics.org>:
> Johannes Schaub <schaub.johannes@googlemail.com> writes:
>
> | 2014-03-16 1:17 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> | > On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub
> | > <schaub.johannes@googlemail.com> wrote:
> | >>
> | >> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
> | >> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
> | >> > <andrewtomazos@gmail.com>
> | >> > wrote:
> | >> >>
> | >> >> Is the following supposed to be ill-formed according to the current
> | >> >> draft?
> | >> >>
> | >> >> template<class> constexpr auto X = 42;
> | >> >>
> | >> >> int main()
> | >> >> {
> | >> >>         static_assert(X<int> == 42, "");
> | >> >> }
> | >> >>
> | >> >>
> | >> >> [dcl.spec.auto]/4 says that auto is allowed when declaring variables in
> | >> >> namespace-scope, but doesn't explicitly say in variable templates -
> | >> >> consequently this is ill-formed.
> | >> >
> | >> >
> | >> > A specialization of a variable template is a variable, so this is
> | >> > allowed.
> | >> >
> | >>
> | >> I don't understand this reason. The following is not a specialization
> | >> of a variable template, is it?
> | >>
> | >>    template<class> constexpr auto X = 42;
> | >>
> | >> The Standard says in 7.1.6.4p6, "A program that uses auto or
> | >> decltype(auto) in a context not explicitly allowed in this section is
> | >> ill-formed."
> | >>
> | >> The section does not explicitly allow "auto" for variable templates.
> | >> Why does it matter that the specialization of that template is a
> | >> variable?
> | >
> | >
> | > Because the validity of a template isn't governed by the usual language
> | > rules. 14.6/8: "No diagnostic shall be issued for a template for which a
> | > valid specialization can be generated."
> | >
> |
> | It's also not clear to me where to draw the line. Consider
> |
> | class Y {
> |   typedef int type;
> | };
> |
> | template<Y::type N>
> | struct X { };
> |
> | The specialization of this template does not have template parameters,
>
> I don't understand why this particular observation is important.  Could
> you elaborate?
>

Since the template parameter is what is being ill-formed, it is
important whether or not it will be part of the specialization of the
template. If it is part of it, the specialization will be ill-formed.
If it is not part of it, the specialization doesn't contain anything
that is ill-formed, so I would conclude that the specialization will
be well-formed and so because "a valid specializaion can be
generated", no diagnostic shall be given.

> | since it's a normal class. A diangostic should therefor not be
> | generated for the class template, since the specialization is valid.
> | However, clang complains
> |
> | "main.cpp:5:13: error: 'type' is a private member of 'Y'"
>
> The issue here is different: it is the declaration itself that is invalid
> in the sense that the declaration of the template (regardless of whether
> it can have a specialization) uses an inaccessible name.
>

I understand that the example I gave is intended to be ill-formed. The
intent seems to be something like this: If the rule violation that
would render the template ill-formed appears as part of the
"declaration" of the template-declaration, then this is not really an
error, as long as a valid specialization can be generated for it. Or
perhaps even this still doesn't capture the real intent of the rule.

In my example, the rule violation appears not as part of the
"declaration", but outside of it and hence the template is still
ill-formed. But this isn't at all stated by the Standard, or I'm just
blind and can't read.

I guess what I would like is an example in the spec that shows what is
meant by it. Perhaps the example above with the access error (or
something better), and the example with "auto" (or something better).
That would avoid misunderstandings in the future.

--

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

.

--Apple-Mail=_208D01BC-5149-4CFF-B34F-699AD30F560D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-17, at 2:17 AM, Johannes Schaub <schaub.johannes@googlemail.com>=
 wrote:

> Since the template parameter is what is being ill-formed, it is
> important whether or not it will be part of the specialization of the
> template.

Because the template parameter declaration is ill-formed, it gets diagnosed=
 immediately and does not form any larger structure. Hence there is no temp=
late to be specialized in the first place. There is no "being ill-formed", =
because ill-formedness implies the state of not being.

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

--Apple-Mail=_208D01BC-5149-4CFF-B34F-699AD30F560D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;03&ndash;17, at 2:17 AM, Johannes Schaub &lt;<a href=3D"mailto:schaub=
..johannes@googlemail.com">schaub.johannes@googlemail.com</a>&gt; wrote:</di=
v><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div st=
yle=3D"font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Since t=
he template parameter is what is being ill-formed, it is<br>important wheth=
er or not it will be part of the specialization of the<br>template. </div><=
/blockquote><div><br></div><div>Because the template parameter declaration =
is ill-formed, it gets diagnosed immediately and does not form any larger s=
tructure. Hence there is no template to be specialized in the first place. =
There is no &ldquo;being ill-formed&rdquo;, because ill-formedness implies =
the state of <i>not being</i>.</div></div><br></body></html>

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

--Apple-Mail=_208D01BC-5149-4CFF-B34F-699AD30F560D--

.

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

Am 17.03.2014 01:46 schrieb "David Krauss" <potswa@gmail.com>:
>
>
> On 2014-03-17, at 2:17 AM, Johannes Schaub <schaub.johannes@googlemail.com>
wrote:
>
>> Since the template parameter is what is being ill-formed, it is
>> important whether or not it will be part of the specialization of the
>> template.
>
>
> Because the template parameter declaration is ill-formed, it gets
diagnosed immediately and does not form any larger structure. Hence there
is no template to be specialized in the first place. There is no "being
ill-formed", because ill-formedness implies the state of not being.
>

You must be seeing some difference to the auto case in the alias template.
What is this difference, precisely?

> --

--

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

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

<p dir=3D"ltr"><br>
Am 17.03.2014 01:46 schrieb &quot;David Krauss&quot; &lt;<a href=3D"mailto:=
potswa@gmail.com">potswa@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;<br>
&gt; On 2014&ndash;03&ndash;17, at 2:17 AM, Johannes Schaub &lt;<a href=3D"=
mailto:schaub.johannes@googlemail.com">schaub.johannes@googlemail.com</a>&g=
t; wrote:<br>
&gt;<br>
&gt;&gt; Since the template parameter is what is being ill-formed, it is<br=
>
&gt;&gt; important whether or not it will be part of the specialization of =
the<br>
&gt;&gt; template.<br>
&gt;<br>
&gt;<br>
&gt; Because the template parameter declaration is ill-formed, it gets diag=
nosed immediately and does not form any larger structure. Hence there is no=
 template to be specialized in the first place. There is no &ldquo;being il=
l-formed&rdquo;, because ill-formedness implies the state of not being.<br>

&gt;</p>
<p dir=3D"ltr">You must be seeing some difference to the auto case in the a=
lias template. What is this difference, precisely?<br></p>
<p dir=3D"ltr">&gt; -- <br>
</p>

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

--047d7b6dc31eb3573204f4caeaa3--

.

David Krauss <potswa@gmail.com> writes:

| On 2014=E2=80=9303=E2=80=9316, at 3:49 PM, Gabriel Dos Reis <gdr@axiomati=
cs.org>
| wrote:
|=20
|     The general model of C++ templates, since day 1, is that if decl
|     is a
|     valid declaration, then
|    =20
|     =C2=A0=C2=A0template <parameter-list> decl
|    =20
|     is also a valid declaration.
|=20
|=20
| Well, Johannes=E2=80=99 code is specifically a counterexample to that rul=
e,
| because the error is in the parameter-list.

I am not sure why that is a counter example:  if the parameter is
non-sensical, it can't be a declaration.

| It seems fairly obvious that an invalid template parameter declaration
| is diagnosed when translating it,

Yes, which is why I don't understand why it is a counterexample.

| not at instantiation. If his code
| exposes a defect, it belongs to name lookup, not the instantiation
| process.=20

I am not quite sure what you think is the defect.

| (Should=C2=A0that name be accessible, if the template had a friend
| declaration? However it is not a friend in the example.)
|=20
| His argument, though, seems to be that there is a slippery slope of
| allowing things that aren=E2=80=99t specifically specified. I don=E2=80=
=99t buy it.

I don't understand either.

-- Gaby

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

.

Johannes Schaub <schaub.johannes@googlemail.com> writes:

| 2014-03-16 8:53 GMT+01:00 Gabriel Dos Reis <gdr@axiomatics.org>:
| > Johannes Schaub <schaub.johannes@googlemail.com> writes:
| >
| > | 2014-03-16 1:17 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
| > | > On Sat, Mar 15, 2014 at 5:13 PM, Johannes Schaub
| > | > <schaub.johannes@googlemail.com> wrote:
| > | >>
| > | >> 2014-03-16 0:38 GMT+01:00 Richard Smith <richard@metafoo.co.uk>:
| > | >> > On Sat, Mar 15, 2014 at 1:46 PM, Andrew Tomazos
| > | >> > <andrewtomazos@gmail.com>
| > | >> > wrote:
| > | >> >>
| > | >> >> Is the following supposed to be ill-formed according to the current
| > | >> >> draft?
| > | >> >>
| > | >> >> template<class> constexpr auto X = 42;
| > | >> >>
| > | >> >> int main()
| > | >> >> {
| > | >> >>         static_assert(X<int> == 42, "");
| > | >> >> }
| > | >> >>
| > | >> >>
| > | >> >> [dcl.spec.auto]/4 says that auto is allowed when declaring
| > | >> >> variables in
| > | >> >> namespace-scope, but doesn't explicitly say in variable templates -
| > | >> >> consequently this is ill-formed.
| > | >> >
| > | >> >
| > | >> > A specialization of a variable template is a variable, so this is
| > | >> > allowed.
| > | >> >
| > | >>
| > | >> I don't understand this reason. The following is not a specialization
| > | >> of a variable template, is it?
| > | >>
| > | >>    template<class> constexpr auto X = 42;
| > | >>
| > | >> The Standard says in 7.1.6.4p6, "A program that uses auto or
| > | >> decltype(auto) in a context not explicitly allowed in this section is
| > | >> ill-formed."
| > | >>
| > | >> The section does not explicitly allow "auto" for variable templates.
| > | >> Why does it matter that the specialization of that template is a
| > | >> variable?
| > | >
| > | >
| > | > Because the validity of a template isn't governed by the usual language
| > | > rules. 14.6/8: "No diagnostic shall be issued for a template for which a
| > | > valid specialization can be generated."
| > | >
| > |
| > | It's also not clear to me where to draw the line. Consider
| > |
| > | class Y {
| > |   typedef int type;
| > | };
| > |
| > | template<Y::type N>
| > | struct X { };
| > |
| > | The specialization of this template does not have template parameters,
| >
| > I don't understand why this particular observation is important.  Could
| > you elaborate?
| >
|
| Since the template parameter is what is being ill-formed,

If the parameter is non-sensical, then we don't have a template declaration.

| it is
| important whether or not it will be part of the specialization of the
| template.

If the template declaration itself is non-sensical, we don't have a
declaration to specialize; do we?

| If it is part of it, the specialization will be ill-formed.
| If it is not part of it, the specialization doesn't contain anything
| that is ill-formed, so I would conclude that the specialization will
| be well-formed and so because "a valid specializaion can be
| generated", no diagnostic shall be given.
|
| > | since it's a normal class. A diangostic should therefor not be
| > | generated for the class template, since the specialization is valid.
| > | However, clang complains
| > |
| > | "main.cpp:5:13: error: 'type' is a private member of 'Y'"
| >
| > The issue here is different: it is the declaration itself that is invalid
| > in the sense that the declaration of the template (regardless of whether
| > it can have a specialization) uses an inaccessible name.
| >
|
| I understand that the example I gave is intended to be ill-formed. The
| intent seems to be something like this: If the rule violation that
| would render the template ill-formed appears as part of the
| "declaration" of the template-declaration, then this is not really an
| error, as long as a valid specialization can be generated for it. Or
| perhaps even this still doesn't capture the real intent of the rule.
|
| In my example, the rule violation appears not as part of the
| "declaration", but outside of it and hence the template is still
| ill-formed. But this isn't at all stated by the Standard, or I'm just
| blind and can't read.

I guess I am not getting why it is ill-formed.

| I guess what I would like is an example in the spec that shows what is
| meant by it. Perhaps the example above with the access error (or
| something better), and the example with "auto" (or something better).
| That would avoid misunderstandings in the future.

If you believe it is ill-formed, then an example that show it is
well-formed would not help, right?

-- Gaby

--

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

.

David Krauss <potswa@gmail.com> writes:

| On 2014=E2=80=9303=E2=80=9317, at 2:17 AM, Johannes Schaub
| <schaub.johannes@googlemail.com> wrote:
|=20
|     Since the template parameter is what is being ill-formed, it is
|     important whether or not it will be part of the specialization of
|     the
|     template.=20
|=20
|=20
| Because the template parameter declaration is ill-formed, it gets
| diagnosed immediately and does not form any larger structure. Hence
| there is no template to be specialized in the first place.

Exactly.

-- Gaby

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

.

2014-03-19 19:14 GMT+01:00 Gabriel Dos Reis <gdr@axiomatics.org>:
> David Krauss <potswa@gmail.com> writes:
>
> | On 2014-03-16, at 3:49 PM, Gabriel Dos Reis <gdr@axiomatics.org>
> | wrote:
> |
> |     The general model of C++ templates, since day 1, is that if decl
> |     is a
> |     valid declaration, then
> |
> |       template <parameter-list> decl
> |
> |     is also a valid declaration.
> |
> |
> | Well, Johannes' code is specifically a counterexample to that rule,
> | because the error is in the parameter-list.
>
> I am not sure why that is a counter example:  if the parameter is
> non-sensical, it can't be a declaration.
>

I was playing devil's advocate. You are saying that the following is a template

   template<class> constexpr auto X = 42;

But the "decl" is non-sensical, because while it is allowed to put
"auto" in the declaration of a variable, it is not allowed in the
declaration of a variable template.

> | It seems fairly obvious that an invalid template parameter declaration
> | is diagnosed when translating it,
>
> Yes, which is why I don't understand why it is a counterexample.
>

Yes, I agree to this.

> | not at instantiation. If his code
> | exposes a defect, it belongs to name lookup, not the instantiation
> | process.
>
> I am not quite sure what you think is the defect.
>

I don't understand this sentence either.

--

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

.

2014-03-19 19:17 GMT+01:00 Gabriel Dos Reis <gdr@axiomatics.org>:
> Johannes Schaub <schaub.johannes@googlemail.com> writes:
>
> | it is
> | important whether or not it will be part of the specialization of the
> | template.
>
> If the template declaration itself is non-sensical, we don't have a
> declaration to specialize; do we?
>

Right, but the same can be said about "decl" in "template<params>
decl". If "decl" is non-sensical, then we don't have a declaration to
specialize.

> | If it is part of it, the specialization will be ill-formed.
> | If it is not part of it, the specialization doesn't contain anything
> | that is ill-formed, so I would conclude that the specialization will
> | be well-formed and so because "a valid specializaion can be
> | generated", no diagnostic shall be given.
> |
> | > | since it's a normal class. A diangostic should therefor not be
> | > | generated for the class template, since the specialization is valid.
> | > | However, clang complains
> | > |
> | > | "main.cpp:5:13: error: 'type' is a private member of 'Y'"
> | >
> | > The issue here is different: it is the declaration itself that is invalid
> | > in the sense that the declaration of the template (regardless of whether
> | > it can have a specialization) uses an inaccessible name.
> | >
> |
> | I understand that the example I gave is intended to be ill-formed. The
> | intent seems to be something like this: If the rule violation that
> | would render the template ill-formed appears as part of the
> | "declaration" of the template-declaration, then this is not really an
> | error, as long as a valid specialization can be generated for it. Or
> | perhaps even this still doesn't capture the real intent of the rule.
> |
> | In my example, the rule violation appears not as part of the
> | "declaration", but outside of it and hence the template is still
> | ill-formed. But this isn't at all stated by the Standard, or I'm just
> | blind and can't read.
>
> I guess I am not getting why it is ill-formed.
>

Because it uses "auto" in a context not explicitly allowed (the
context here is a variable template). The rule that Richard quoted is
intended to make it well-formed eventually, but the wording does not
actually convey that intent IMO (see below).

> | I guess what I would like is an example in the spec that shows what is
> | meant by it. Perhaps the example above with the access error (or
> | something better), and the example with "auto" (or something better).
> | That would avoid misunderstandings in the future.
>
> If you believe it is ill-formed, then an example that show it is
> well-formed would not help, right?
>

I don't believe anymore that it is ill-formed, after you explained the
model of templates and a compiler writer (Richard) explained the model
they assume the Standard to take.

The sentence Richard quoted is "No diagnostic shall be issued for a
template for which a valid specialization can be generated.", which is
the reason that the ill-formed template isn't actually diagnosed. The
next sentence is "If no valid specialization can be generated for a
template, and that template is not instantiated, the template is
ill-formed, no diagnostic required.". And the example that it shows is
(shortened)

    template<typename T> void g() { +; }

Now, this surely is a soup of tokens, but not a template. But the
sentence is intended to be applicable to this code, so it makes the
"template" be "ill-formed; no diagnostic required", for the benefit of
compilers that just collect a token soup when they are given a
template, instead of parsing them completely. Well, this state of
affairs may be tolerable, because we have an example that shows the
real intent of this rule.

Similar things seem to go on with th efirst sentence that Richard
quotes, where an ill-formed template is required to be *not* diagnosed
if certain things apply. IMO it is *not* tolerable that there is no
example that shows what this is intended to mean.

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

.

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

On Wed, Mar 19, 2014 at 12:26 PM, Johannes Schaub <
schaub.johannes@googlemail.com> wrote:

> 2014-03-19 19:17 GMT+01:00 Gabriel Dos Reis <gdr@axiomatics.org>:
> > Johannes Schaub <schaub.johannes@googlemail.com> writes:
> >
> > | it is
> > | important whether or not it will be part of the specialization of the
> > | template.
> >
> > If the template declaration itself is non-sensical, we don't have a
> > declaration to specialize; do we?
> >
>
> Right, but the same can be said about "decl" in "template<params>
> decl". If "decl" is non-sensical, then we don't have a declaration to
> specialize.
>
> > | If it is part of it, the specialization will be ill-formed.
> > | If it is not part of it, the specialization doesn't contain anything
> > | that is ill-formed, so I would conclude that the specialization will
> > | be well-formed and so because "a valid specializaion can be
> > | generated", no diagnostic shall be given.
> > |
> > | > | since it's a normal class. A diangostic should therefor not be
> > | > | generated for the class template, since the specialization is
> valid.
> > | > | However, clang complains
> > | > |
> > | > | "main.cpp:5:13: error: 'type' is a private member of 'Y'"
> > | >
> > | > The issue here is different: it is the declaration itself that is
> invalid
> > | > in the sense that the declaration of the template (regardless of
> whether
> > | > it can have a specialization) uses an inaccessible name.
> > | >
> > |
> > | I understand that the example I gave is intended to be ill-formed. The
> > | intent seems to be something like this: If the rule violation that
> > | would render the template ill-formed appears as part of the
> > | "declaration" of the template-declaration, then this is not really an
> > | error, as long as a valid specialization can be generated for it. Or
> > | perhaps even this still doesn't capture the real intent of the rule.
> > |
> > | In my example, the rule violation appears not as part of the
> > | "declaration", but outside of it and hence the template is still
> > | ill-formed. But this isn't at all stated by the Standard, or I'm just
> > | blind and can't read.
> >
> > I guess I am not getting why it is ill-formed.
> >
>
> Because it uses "auto" in a context not explicitly allowed (the
> context here is a variable template). The rule that Richard quoted is
> intended to make it well-formed eventually, but the wording does not
> actually convey that intent IMO (see below).
>
> > | I guess what I would like is an example in the spec that shows what is
> > | meant by it. Perhaps the example above with the access error (or
> > | something better), and the example with "auto" (or something better).
> > | That would avoid misunderstandings in the future.
> >
> > If you believe it is ill-formed, then an example that show it is
> > well-formed would not help, right?
> >
>
> I don't believe anymore that it is ill-formed, after you explained the
> model of templates and a compiler writer (Richard) explained the model
> they assume the Standard to take.
>
> The sentence Richard quoted is "No diagnostic shall be issued for a
> template for which a valid specialization can be generated.", which is
> the reason that the ill-formed template isn't actually diagnosed. The
> next sentence is "If no valid specialization can be generated for a
> template, and that template is not instantiated, the template is
> ill-formed, no diagnostic required.". And the example that it shows is
> (shortened)
>
>     template<typename T> void g() { +; }
>
> Now, this surely is a soup of tokens, but not a template. But the
> sentence is intended to be applicable to this code, so it makes the
> "template" be "ill-formed; no diagnostic required", for the benefit of
> compilers that just collect a token soup when they are given a
> template, instead of parsing them completely. Well, this state of
> affairs may be tolerable, because we have an example that shows the
> real intent of this rule.
>
> Similar things seem to go on with th efirst sentence that Richard
> quotes, where an ill-formed template is required to be *not* diagnosed
> if certain things apply. IMO it is *not* tolerable that there is no
> example that shows what this is intended to mean.


I agree that the standard is unfortunately imprecise here. In

  *template-declaration:*
    template < *template-parameter-list* > *declaration*

it's not really meaningful to ask whether the template has valid
specializations if the *template-parameter-list* is ill-formed. If we
assume that an ill-formed *template-parameter-list* implies that there are
no valid specializations (which seems like a reasonable assumption to me),
then the existing rule works, but a normative statement of something along
these lines would be useful.

Are there problematic cases outside the *template-parameter-list*?

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Mar 19, 2014 at 12:26 PM, Johannes Schaub <span dir=3D"ltr">&lt;<a href=
=3D"mailto:schaub.johannes@googlemail.com" target=3D"_blank">schaub.johanne=
s@googlemail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2014-03-19 19:17 GMT+01:00 Gabriel Dos Reis =
&lt;<a href=3D"mailto:gdr@axiomatics.org">gdr@axiomatics.org</a>&gt;:<br>
<div class=3D"">&gt; Johannes Schaub &lt;<a href=3D"mailto:schaub.johannes@=
googlemail.com">schaub.johannes@googlemail.com</a>&gt; writes:<br>
&gt;<br>
&gt; | it is<br>
&gt; | important whether or not it will be part of the specialization of th=
e<br>
&gt; | template.<br>
&gt;<br>
&gt; If the template declaration itself is non-sensical, we don&#39;t have =
a<br>
&gt; declaration to specialize; do we?<br>
&gt;<br>
<br>
</div>Right, but the same can be said about &quot;decl&quot; in &quot;templ=
ate&lt;params&gt;<br>
decl&quot;. If &quot;decl&quot; is non-sensical, then we don&#39;t have a d=
eclaration to<br>
specialize.<br>
<div class=3D""><br>
&gt; | If it is part of it, the specialization will be ill-formed.<br>
&gt; | If it is not part of it, the specialization doesn&#39;t contain anyt=
hing<br>
&gt; | that is ill-formed, so I would conclude that the specialization will=
<br>
&gt; | be well-formed and so because &quot;a valid specializaion can be<br>
&gt; | generated&quot;, no diagnostic shall be given.<br>
&gt; |<br>
&gt; | &gt; | since it&#39;s a normal class. A diangostic should therefor n=
ot be<br>
&gt; | &gt; | generated for the class template, since the specialization is=
 valid.<br>
&gt; | &gt; | However, clang complains<br>
&gt; | &gt; |<br>
&gt; | &gt; | &quot;main.cpp:5:13: error: &#39;type&#39; is a private membe=
r of &#39;Y&#39;&quot;<br>
&gt; | &gt;<br>
&gt; | &gt; The issue here is different: it is the declaration itself that =
is invalid<br>
&gt; | &gt; in the sense that the declaration of the template (regardless o=
f whether<br>
&gt; | &gt; it can have a specialization) uses an inaccessible name.<br>
&gt; | &gt;<br>
&gt; |<br>
&gt; | I understand that the example I gave is intended to be ill-formed. T=
he<br>
&gt; | intent seems to be something like this: If the rule violation that<b=
r>
&gt; | would render the template ill-formed appears as part of the<br>
&gt; | &quot;declaration&quot; of the template-declaration, then this is no=
t really an<br>
&gt; | error, as long as a valid specialization can be generated for it. Or=
<br>
&gt; | perhaps even this still doesn&#39;t capture the real intent of the r=
ule.<br>
&gt; |<br>
&gt; | In my example, the rule violation appears not as part of the<br>
&gt; | &quot;declaration&quot;, but outside of it and hence the template is=
 still<br>
&gt; | ill-formed. But this isn&#39;t at all stated by the Standard, or I&#=
39;m just<br>
&gt; | blind and can&#39;t read.<br>
&gt;<br>
&gt; I guess I am not getting why it is ill-formed.<br>
&gt;<br>
<br>
</div>Because it uses &quot;auto&quot; in a context not explicitly allowed =
(the<br>
context here is a variable template). The rule that Richard quoted is<br>
intended to make it well-formed eventually, but the wording does not<br>
actually convey that intent IMO (see below).<br>
<div class=3D""><br>
&gt; | I guess what I would like is an example in the spec that shows what =
is<br>
&gt; | meant by it. Perhaps the example above with the access error (or<br>
&gt; | something better), and the example with &quot;auto&quot; (or somethi=
ng better).<br>
&gt; | That would avoid misunderstandings in the future.<br>
&gt;<br>
&gt; If you believe it is ill-formed, then an example that show it is<br>
&gt; well-formed would not help, right?<br>
&gt;<br>
<br>
</div>I don&#39;t believe anymore that it is ill-formed, after you explaine=
d the<br>
model of templates and a compiler writer (Richard) explained the model<br>
they assume the Standard to take.<br>
<br>
The sentence Richard quoted is &quot;No diagnostic shall be issued for a<br=
>
template for which a valid specialization can be generated.&quot;, which is=
<br>
the reason that the ill-formed template isn&#39;t actually diagnosed. The<b=
r>
next sentence is &quot;If no valid specialization can be generated for a<br=
>
template, and that template is not instantiated, the template is<br>
ill-formed, no diagnostic required.&quot;. And the example that it shows is=
<br>
(shortened)<br>
<br>
=A0 =A0 template&lt;typename T&gt; void g() { +; }<br>
<br>
Now, this surely is a soup of tokens, but not a template. But the<br>
sentence is intended to be applicable to this code, so it makes the<br>
&quot;template&quot; be &quot;ill-formed; no diagnostic required&quot;, for=
 the benefit of<br>
compilers that just collect a token soup when they are given a<br>
template, instead of parsing them completely. Well, this state of<br>
affairs may be tolerable, because we have an example that shows the<br>
real intent of this rule.<br>
<br>
Similar things seem to go on with th efirst sentence that Richard<br>
quotes, where an ill-formed template is required to be *not* diagnosed<br>
if certain things apply. IMO it is *not* tolerable that there is no<br>
example that shows what this is intended to mean.</blockquote><div><br></di=
v><div>I agree that the standard is unfortunately imprecise here. In</div><=
div><br></div><div>=A0 <i>template-declaration:</i></div><div>=A0 =A0 <font=
 face=3D"courier new, monospace">template</font> <font face=3D"courier new,=
 monospace">&lt;</font> <i>template-parameter-list</i> <font face=3D"courie=
r new, monospace">&gt;</font> <i>declaration</i></div>
<div><br></div><div>it&#39;s not really meaningful to ask whether the templ=
ate has valid specializations if the <i>template-parameter-list</i> is ill-=
formed. If we assume that an ill-formed <i>template-parameter-list</i> impl=
ies that there are no valid specializations (which seems like a reasonable =
assumption to me), then the existing rule works, but a normative statement =
of something along these lines would be useful.</div>
<div><br></div><div>Are there problematic cases outside the <i>template-par=
ameter-list</i>?</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d84ef59c27d04f4facf5a--

.

Johannes Schaub <schaub.johannes@googlemail.com> writes:

| 2014-03-19 19:14 GMT+01:00 Gabriel Dos Reis <gdr@axiomatics.org>:
| > David Krauss <potswa@gmail.com> writes:
| >
| > | On 2014-03-16, at 3:49 PM, Gabriel Dos Reis <gdr@axiomatics.org>
| > | wrote:
| > |
| > |     The general model of C++ templates, since day 1, is that if decl
| > |     is a
| > |     valid declaration, then
| > |
| > |       template <parameter-list> decl
| > |
| > |     is also a valid declaration.
| > |
| > |
| > | Well, Johannes' code is specifically a counterexample to that rule,
| > | because the error is in the parameter-list.
| >
| > I am not sure why that is a counter example:  if the parameter is
| > non-sensical, it can't be a declaration.
| >
|
| I was playing devil's advocate. You are saying that the following is a template
|
|    template<class> constexpr auto X = 42;
|
| But the "decl" is non-sensical, because while it is allowed to put
| "auto" in the declaration of a variable, it is not allowed in the
| declaration of a variable template.

Why?

-- Gaby

--

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

.

--Apple-Mail=_2B233623-063C-4802-BD47-FBF8DF5BAF4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-03-20, at 2:14 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:

> | not at instantiation. If his code
> | exposes a defect, it belongs to name lookup, not the instantiation
> | process.=20
>=20
> I am not quite sure what you think is the defect.

I don't think there is, I'm just imagining a use-case similar to his exampl=
e, where the user wants to use a private type to declare a non-type paramet=
er. This is currently impossible at namespace scope. (There might already b=
e a DR about it.)


On 2014-03-20, at 3:14 AM, Johannes Schaub <schaub.johannes@googlemail.com>=
 wrote:

> I was playing devil's advocate. You are saying that the following is a te=
mplate

"Devil's advocate" means arguing a hypothetical point which one does not tr=
uly believe. Is this the case?

--

Since this argument will continue going in circles, here is my suggestion f=
rom a private email to Johannes:

> FWIW, I'd recommend changing "This use is allowed when declaring variable=
s in..." to "This use is allowed in variable declarations in..." since the =
template declaration unequivocally encloses a variable declaration, whether=
 or that declaration declares a variable or a variable template specializat=
ion set.

To be clear, the text is in [decl.spec.auto] 7.1.6.4/4 and the fix is inten=
ded to adjust it to match [temp] 14/1, "A declaration introduced by a templ=
ate declaration of a variable is a variable template." The wording there is=
 a little imprecise, and should perhaps be "A template-declaration in which=
 the declaration declares a variable, declares a variable template." Which =
is utterly the height of redundant obviousness, and I apologize.

In any case, the idea already presumed by the standard is that a variable d=
eclaration is "almost" a purely syntactic construct, such that we can decid=
e that it's such before knowing what it has declared.

TL;DR: auto needs to be valid for variable declarations even if they don't =
declare variables. But it's not causing any problems.

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

--Apple-Mail=_2B233623-063C-4802-BD47-FBF8DF5BAF4F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html=
 charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/=
html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=
=3D"text/html charset=3Dwindows-1252"></head><body style=3D"word-wrap: brea=
k-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><=
br><div><div>On 2014&ndash;03&ndash;20, at 2:14 AM, Gabriel Dos Reis &lt;<a=
 href=3D"mailto:gdr@axiomatics.org">gdr@axiomatics.org</a>&gt; wrote:</div>=
<br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">| not at =
instantiation. If his code</blockquote><blockquote type=3D"cite">| exposes =
a defect, it belongs to name lookup, not the instantiation<br>| process. <b=
r><br>I am not quite sure what you think is the defect.<br></blockquote><di=
v><br></div><div>I don&rsquo;t think there is, I&rsquo;m just imagining a u=
se-case similar to his example, where the user wants to use a private type =
to declare a non-type parameter. This is currently impossible at namespace =
scope. (There might already be a DR about it.)</div></div><div><br></div><d=
iv><br></div>On 2014&ndash;03&ndash;20, at 3:14 AM, Johannes Schaub &lt;<a =
href=3D"mailto:schaub.johannes@googlemail.com">schaub.johannes@googlemail.c=
om</a>&gt; wrote:<div><br><div><blockquote type=3D"cite">I was playing devi=
l's advocate. You are saying that the following is a template<br></blockquo=
te><br></div></div><div>&ldquo;Devil&rsquo;s advocate&rdquo; means arguing =
a hypothetical point which one does not truly believe. Is this the case?</d=
iv><div><br></div><div>&mdash;</div><div><br></div><div>Since this argument=
 will continue going in circles, here is my suggestion from a private email=
 to Johannes:</div><div><br></div><div><blockquote type=3D"cite">FWIW, I&rs=
quo;d recommend changing &ldquo;This use is allowed when declaring variable=
s in&hellip;&rdquo; to &ldquo;This use is allowed in variable declarations =
in&hellip;&rdquo; since the template declaration unequivocally encloses a v=
ariable declaration, whether or that declaration declares a variable or a v=
ariable template specialization set.</blockquote><br></div><div>To be clear=
, the text is in [decl.spec.auto] 7.1.6.4/4 and the fix is intended to adju=
st it to match [temp] 14/1, &ldquo;A declaration introduced by a template d=
eclaration&nbsp;of a variable is a&nbsp;variable template.&rdquo; The wordi=
ng there is a little imprecise, and should perhaps be &ldquo;A <i>template-=
declaration</i> in which the <i>declaration</i> declares a variable, declar=
es a variable template.&rdquo; Which is utterly the height of redundant obv=
iousness, and I apologize.</div><div><br></div><div>In any case, the idea a=
lready presumed by the standard is that a variable declaration is &ldquo;al=
most&rdquo; a purely syntactic construct, such that we can decide that it&r=
squo;s such before knowing what it has declared.</div><div><br></div><div>T=
L;DR: <font face=3D"Courier">auto</font>&nbsp;needs to be valid for variabl=
e declarations even if they don&rsquo;t declare variables. But it&rsquo;s n=
ot causing any problems.</div><div><br></div></body></html>

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

--Apple-Mail=_2B233623-063C-4802-BD47-FBF8DF5BAF4F--

.