digitalmars.D - final invariant request = disallow meaningless attributes
- Deewiant (30/30) Jun 23 2007 With the new constants, people, including many who have used D for a lon...
- Ary Manzana (8/20) Jun 23 2007 I totally agree with this.
- Jason House (13/23) Jun 24 2007 I think some exception is needed for generic programming. Redundancy
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
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
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