invariant/const class storage class

Sean Kelly sean at invisibleduck.org
Wed Oct 1 10:34:06 PDT 2008


Yigal Chripun wrote:
> Walter Bright wrote:
>> Simen Kjaeraas wrote:
>>> Is this really correct behavior? How then are we supposed to
>>> initialize our
>>> invariant objects?
>> Currently, create them as mutable ones, then cast them to invariant.
> 
> I understand casting as breaking the type system. shouldn't there be a
> way to create invariant objects without the cast?
> an invariant constructor seems a good way to solve this. any plans on
> adding such a feature to D2?

Definitely.  I can't imagine that the current situation is any more than 
an incomplete design.  After all, everything needs to be initialized.

> I think it can work like this:
> 
> class A {
>   this(params) {}   // [1]
>   invariant this(params) {}  // [2]
> }

I don't see any point in having a separate 'invariant' ctor, given my 
point about initialization above.  It should be perfectly legal to 
simply do:

     class A {}
     invariant a = new A;

Just as it should be legal to do:

     string s = "a" ~ "b";

That both are illegal right now is ridiculous.  Perhaps the "Polysemous 
Value" idea can apply here.  Since the compiler can clearly detect that 
in both cases the value being assigned is not shared it should be 
perfectly acceptable to implicitly convert its type to a compatible but 
stronger type.


Sean



More information about the Digitalmars-d mailing list