Why D const is annoying

[H. S. Teoh]

On Wed, May 02, 2012 at 05:16:26PM +0200, bearophile wrote:
> H. S. Teoh:
> 
> >Doesn't it already?
> 
> Right, this:
> 
> class Foo {}
> void main() @safe {
>      const f1 = new Foo;
>      auto f2 = cast(Foo)f1;
> }
> 
> 
> Gives:
> test.d(5): Error: cast from const(Foo) to test.Foo not allowed in
> safe code
[...]

Thought so.

One area where I'd like const to be improved, though, is a way to
indicate that const-ness depends on the arguments, specifically, on the
behaviour of a delegate argument. For non-delegate arguments we have
inout (which is also its own minefield, but anyway), but it sucks that
opApply can never be marked @safe, const, or pure because there's no
guarantee at all what the delegate will do. (Forcing the delegate to be
any of the above is not really an option, because what if you *needed*
to call opApply with an impure delegate?)

This on its own is no big deal, but the thing is, const, pure, and @safe
are all "viral". All it takes is for a single nested function to call
opApply somewhere, and suddenly the whole function call chain can no
longer be marked const/pure/@safe.


T

-- 
Let X be the set not defined by this sentence...