http://d.puremagic.com/issues/show_bug.cgi?id=2716
--- Comment #9 from Stewart Gordon <s...@iname.com> 2009-07-14 05:38:02 PDT --- (In reply to comment #8) > > "storage class has no effect" seems to be the wrong wording. > > I'll change it if you come up with a nicer error message. "cannot be auto" > would've been consistent with other error messages of this kind, but I thought > the "has no effect" one was nicer. But "has no effect" reads to me to the effect that the compiler is supposed to just ignore it, rendering the fact that the error is generated confusing to the user. How about "both auto and explicit type given"? > > Firstly, it'll be a case of doesn't make sense rather than has no effect; > > secondly, this is making it not a storage class at all. > > That's arguable. My reasoning was that as a do-nothing storage class, auto > makes sense everywhere. Its only 'effect' is to allow type inference in the > absence of another storage class. The treatment of auto in this context as a storage class seems to be a hack to simplify parsing of declarations, which is useful only because of auto's ambiguity. If we get rid of auto's ambiguity as is being suggested, we should get rid of this hack while we're at it. More logical is to handle auto as a placeholder for a type in auto-typed declarations, as a direct part of the AutoDeclaration syntax (as I must've OUAT thought it already was). Something like (using * and + with their regexp meanings) AutoDeclaration: Attribute* auto Identifier = AssignExpression ; Attribute+ Identifier = AssignExpression ; Attribute* auto Attribute+ Identifier = AssignExpression ; (this last form is for backward compatibility, but could be removed or deprecated one day) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------