2716 – Confusion of auto and scope as the class attribute

auto class B {}
void main()
{
	B x;
}
a.d(4): variable a.main.x reference to scope class must be scope

An auto class and a scope class are the same thing. What do you think auto means in this context?

That use of auto is supposed to be going away. I've reopened and assigned to 2.x.

What is this different something that auto in this context means now? I can't find it by a quick look through the docs.

The old concept of 'auto' meaning 'scope' should be dead. It's death started before the 1.0 release (if I remember my history correctly, don't feel like searching the changelogs). It appears that it isn't in this case. 'auto class' should be either an error or a no-op depending on your philosophy of redundant type prefixes.

No redundant type prefix here. auto either
(a) still means the same as scope, IWC this whole bug report is nonsense
(b) makes no sense here at all, IWC the rejects-valid keyword here is nonsense - it's diagnostic here, possibly accepts-invalid
But there's something wrong - auto is still given on attribute.html, but the way it's used there it doesn't seem to be an attribute.
Brad, while I have your ear, are you planning to catch up on the issues filed here against puremagic.com itself any time soon?

Created attachment 421 [details] 
Do not consider auto to mean scope.
This is a patch against LDC's DMDFE. It removes the remaining instances of auto meaning scope and makes 'auto class C { ... }' and 'auto C c;' an 'Error: storage class has no effect: auto'. See also bug 3118 .

(In reply to comment #6)
> Created an attachment (id=421) [details]
> Do not consider auto to mean scope.
> 
> This is a patch against LDC's DMDFE. It removes the remaining instances of auto
> meaning scope and makes 'auto class C { ... }' and 'auto C c;' an 'Error:
> storage class has no effect: auto'. See also bug 3118 .
"storage class has no effect" seems to be the wrong wording. 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.
Moreover, should we get rid of it straight off, or deprecate it first?

> "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.
> 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.
> Moreover, should we get rid of it straight off, or deprecate it first?
I would've if it had ever been in the D1 spec, but as far as I remember it's around purely as a holdover from pre-D1.

(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)

(In reply to comment #9)
> How about "both auto and explicit type given"?
Or even "both auto and explicit type given, use scope for RAII" for the benefit of returning D programmers and those otherwise trying to update legacy code.

I've switched the error message to "both auto and explicit type given". auto class C {} will still trigger the "storage class has no effect" one though. I don't think error messages of this kind are avoidable if you want to make directly applying inapplicable storage classes an error.
By the way, bug 3118 would benefit from having a list of attributes and declarations that should trigger an error if combined via direct application. I can't guarantee I'll find the time to work on it though.

(In reply to comment #11)
> I've switched the error message to "both auto and explicit type given". auto
> class C {} will still trigger the "storage class has no effect" one though. I
> don't think error messages of this kind are avoidable if you want to make
> directly applying inapplicable storage classes an error.
Probably 99% of poorly written error messages can be improved if only one stops to think about it.
How about "auto cannot be applied to classes" or "auto can only be applied to variable declarations"? We could use the same format for all illegal uses of attributes.
Of course, the relevance of this to auto'll change when/if the grammar change proposed in comment 9 is implemented....

(In reply to comment #1)
> An auto class and a scope class are the same thing. What do you think auto
> means in this context?
I think "auto class" must be an error, because a scoped class is "scope class" already.

(In reply to comment #13)
> (In reply to comment #1)
> > An auto class and a scope class are the same thing. What do you think auto
> > means in this context?
> 
> I think "auto class" must be an error, because a scoped class is "scope class"
> already.
This as a meaning of auto may have been removed from the spec, but AIUI it was never the intention to withdraw it the moment scope was introduced.

Created attachment 636 [details] 
Update previous patch to tip of svn
I've updated this diff to the the current tip of svn 493.
I altered the error messages to point suggest that the user probably wants to use the scope storage class when it finds the deprecated use of auto.
I've also run this through the dmd test suite (which needs some corresponding changes that I'll send to Walter privately).

http://www.dsource.org/projects/dmd/changeset/639 

Thank you for your great job!
However, this invalid code is accepted yet.
auto class A{} // <-- not "scope"
void main()
{
	scope a = new A();
}

Oh! Sorry...
This issue is already fixed.