D const design rationale

Lars Ivar Igesund larsivar at igesund.net
Fri Jun 22 10:56:09 PDT 2007


Daniel Keep wrote:

> 
> 
> Sean Kelly wrote:
>> ...
>> 
>> final
>> const
>> final const
>> 
>> And that's it.  'final' means a reference cannot be rebound, 'const'
>> means the data cannot be altered (through the reference), and 'final
>> const' means that both the reference is frozen and the data cannot be
>> changed.  And that's it.  That the existence of invariant required the
>> addition of parenthesis on class invariants just serves to strengthen
>> the argument in my mind.  So in short, I'm just not convinced that
>> 'invariant' provides enough utility to warrant the cost in complexity
>> and broken consistency (unittest doesn't require parens, so why does
>> invariant?).
> 
> What makes me uneasy about the above is that final isn't a type
> constructor: it's a storage class.  You're turning it into
> sorta-kinda-but-not-quite both.  So, you end up with:
> 
> final int x;          typeof(x) == int;
> const int y;          typeof(y) == const int;
> final const int z;    typeof(z) == final const int;
> 
> "Wait; why is final part of the last type, but not the first?"  And what
> does this mean if you want a class member with final-style binding, but
> (final const) type semantics?
> 
> final (final const(int*)) foo;
> 
> As opposed to
> 
> final invariant(int*) foo;
> 
> I think the thing here is that you're shifting the complexity from
> invariant into final; instead of invariant meaning two different things
> with two very different appearances, you've got final meaning two
> slightly different things with almost identical looks.
> 
> -- Daniel

I agree with Sean on the proposed system looking unnecessarily complex. I
don't have a problem seeing your points regarding Sean's suggestion, but I
still think he has shown that there still may be room for improvement, and
since many (including me) think the full mechanics of this solution is
somewhat hard to grasp, and many even think it is unnecessary to add to the
language in the first place (I'm not one of those), we should strive even
more than normal to find a solution that works and that is easy to use. I
find it weird if such a great change should be solidified after the first
alpha release in a new branch. Not everyone have the opportunity to test it
the first few days after a release to give feedback.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango



More information about the Digitalmars-d mailing list