[Issue 2716] Confusion of auto and scope as the class attribute

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=2716





--- Comment #9 from Stewart Gordon <smjg at 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: -------