Proposal: new variable definition operator

Chris Nicholson-Sauls ibisbasenji at gmail.com
Sun Apr 22 01:34:31 PDT 2007


jovo wrote:
> Chris Nicholson-Sauls Wrote:
>>> From the D docs (Attributes):
>>> "The auto attribute is used when there are no other attributes
>>> and type inference is desired."
>> Same meaning, slightly different words, to this: "If type inference is desired, and there 
>> is no special storage class, you may specify the explicit default storage class attribute 
>> 'auto' to trigger inference."
>>
> 
> I read this sentence as is: The auto attribute is _only_ used when
> there are no other attributes and type inference is desired. Auto
> has not other meaning.
> 
> And _all_ implementation is consistent.
> Compiler just ignores auto in any other place.
> 
> Look at:
> 
> auto int x;        // global, auto is ignored
> 
> void f() {
>     auto static int x = 12;    // static, auto is ignored
>     ...    
>     auto SomeClass x =  new SomeClass();        // sole exception 
> 
> I suspect this exception is needed for backward compatibility. It is 
> reminiscence of old auto.

A reasonable and likely suspicion.  This back-compat should really be /removed/ and soon, 
I feel.  Your examples don't so much illustrate that 'auto' is being ignored -- although I 
will relent insofar as 'auto' has little real use beside type inference and insanely 
verbose code styles -- but rather illustrate what has always been a quietly uneasy thing 
for me: DMD's choice to silently accept and discard any attributes in a decleration where 
they make no sense or have no meaning.  For example, in the 'auto static int x' 
decleration, I would prefer a compile-time error to the effect of "variable x may have 
only one storage class" rather than it just tossing the former to run with the latter.

I'd even like to see errors on things like "static class Foo" at module scope, unless and 
until this was given some meaning (such as "FQN required for this class").

-- Chris Nicholson-Sauls



More information about the Digitalmars-d mailing list