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...