<p dir="ltr"><br>
On 23 May 2014 09:53, "Aaron Ballman" <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>> wrote:<br>
><br>
> On Thu, May 22, 2014 at 9:04 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> > On Mon, May 19, 2014 at 2:38 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> > wrote:<br>
> >><br>
> >> On Mon, May 19, 2014 at 5:32 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
> >> wrote:<br>
> >> > You're citing the wrong section of the standard in your patch. The<br>
> >> > relevant<br>
> >> > wording is [dcl.stc]p1: "If a storage-class-specifier appears in a<br>
> >> > decl-specifier-seq, [...] the init-declarator-list of the declaration<br>
> >> > shall<br>
> >> > not be empty [...]."<br>
> >><br>
> >> Ah, good to know. I made it down to p9 because we were declaring a<br>
> >> type instead of a member variable, but that makes sense.<br>
> >><br>
> >> > Do we really need to change the code here? Is the new diagnostic better<br>
> >> > than<br>
> >> > the old one?<br>
> >><br>
> >> Old diagnostic: ext-warn "'mutable' is not permitted on a declaration of a<br>
> >> type"<br>
> >> Proposed diagnostic: error "'mutable' can only be applied to member<br>
> >> variables"<br>
> >><br>
> >> Honestly, either works for me in terms of wording.<br>
> >><br>
> >> > Do we have a reason to promote this from ExtWarn to Error just<br>
> >> > for mutable and not for other storage class specifiers?<br>
> >><br>
> >> I was going with error because the other mutable constraint violations<br>
> >> are also errors (including this existing one which I was reusing).<br>
> >> Also, it seems weird to treat this as an extension -- what does this<br>
> >> extension actually provide in terms of benefit for the mutable<br>
> >> keyword? What does a mutable type declaration even mean?<br>
> ><br>
> ><br>
> > It's weird that we allow this for other storage classes too. What does a<br>
> > static type declaration mean? =)<br>
> ><br>
> > No objection to the patch; I think I slightly prefer consistent treatment of<br>
> > 'mutable' over consistent treatment of storage classes on type declarations.<br>
> > But I wonder why we ExtWarn rather than Error'ing here in the other cases,<br>
> > and I'm slightly cautious about changing this without knowing the history.<br>
><br>
> I'm uncertain of the history, but for context:<br>
><br>
> // C++ [dcl.stc]p1:<br>
> //   If a storage-class-specifier appears in a decl-specifier-seq, [...] the<br>
> //   init-declarator-list of the declaration shall not be empty.<br>
> // C++ [dcl.fct.spec]p1:<br>
> //   If a cv-qualifier appears in a decl-specifier-seq, the<br>
> //   init-declarator-list of the declaration shall not be empty.<br>
> //<br>
> // Spurious qualifiers here appear to be valid in C.<br>
> unsigned DiagID = diag::warn_standalone_specifier;<br>
> if (getLangOpts().CPlusPlus)<br>
>   DiagID = diag::ext_standalone_specifier;<br>
><br>
> So I think we treat it as an extension because of C. But that makes no<br>
> sense for mutable anyway, which is why I am overriding that in my<br>
> patch and turning it into an error.<br>
><br>
> I've attached a revised patch that updates the comments to reflect my<br>
> understanding of why this is an error instead of an ExtWarn.</p>
<p dir="ltr">OK, LGTM.</p>
<p dir="ltr">By the same argument, we can probably reject any storage class on a member declaration.</p>