www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - final invariant request = disallow meaningless attributes

reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
With the new constants, people, including many who have used D for a long time,
are more confused than ever before about what certain combinations of attributes
mean. The compiler still accepts interesting code like:

export public public private protected package int apple;

I think this has become a real issue now that the difference, or lack thereof,
between the following isn't obvious:

const           int x = 3;
invariant       int x = 3;
const invariant int x = 3;

As far as I understand, the above are equivalent. Yet the compiler accepts all
three. This is confusing to people who don't fully understand the various
semantics of const, final, and invariant. (I didn't include final above because
I'm not sure myself, but I suppose final would be equivalent as well.)

This has been requested before, but I raise the issue now again - the compiler
should disallow applying attributes that:

1) make no sense in the context, like "private" for a function's local variable
2) override one another, like "public private" or "const invariant" anywhere
3) have an equivalent alternative in the context, like const as a storage class

The third point can be debated, as it requires enforcing a standard, such as
"const int x = 3" over "invariant int x = 3".

As I understand it, the only problem with this would be having to write
special-case code for templates. For instance, if final would only be applicable
to reference types, one would have to duplicate entire templates, with only
minor changes for value types.

For that, I suggest that the first point of the three I mentioned would be
disregarded if the declaration is for a templated type.

I'm not sure if this would solve all the problems - it seems too simple. But I
do think DMD/D getting a bit stricter in this regard would be very helpful.

-- 
Remove ".doesnotlike.spam" from the mail address.
Jun 23 2007
parent reply Ary Manzana <ary esperanto.org.ar> writes:
I totally agree with this.

If one of the purposes of the new modifiers are to provide better 
documenation from within the language itself, then if the compiler 
doesn't warn you if you write

const invariant int x = 3;

then it's counterproductive. Against the meaning of "provide better 
documentation".

Deewiant escribió:
 With the new constants, people, including many who have used D for a long time,
 are more confused than ever before about what certain combinations of
attributes
 mean. The compiler still accepts interesting code like:
 
 export public public private protected package int apple;
 
 I think this has become a real issue now that the difference, or lack thereof,
 between the following isn't obvious:
 
 const           int x = 3;
 invariant       int x = 3;
 const invariant int x = 3;

Jun 23 2007
parent Jason House <jason.james.house gmail.com> writes:
Ary Manzana wrote:
 I totally agree with this.
 
 If one of the purposes of the new modifiers are to provide better 
 documenation from within the language itself, then if the compiler 
 doesn't warn you if you write
 
 const invariant int x = 3;
 
 then it's counterproductive. Against the meaning of "provide better 
 documentation".

I think some exception is needed for generic programming. Redundancy with a templated parameter type should be allowed. class A; class(T) B{ T x; const T y; invariant T z; } B!(A) x; B!(const A) y; B!(invariant A) z; Which instances of B, if any, should result in a compiler error?
Jun 24 2007