Should the "front" range primitive be "const" ?

[Simen Kjærås]

On Thursday, 1 February 2018 at 18:58:15 UTC, H. S. Teoh wrote:
> However, if we go back to the idea of tail-const, we could 
> potentially eliminate the need for casts and also avoid 
> breaking immutable. Basically, the problem with writing 
> const(RefCounted!T) is that it's a one-way street: on the scale 
> of increasing restrictiveness, we have the series:
>
> 	RefCounted!T < RefCounted!(const(T)) < const(RefCounted!T)
>
> Once you've gone all the way down to const(RefCounted!T), you 
> can no
> longer safely back out to RefCounted!(const(T)).
>
> So that means we want to avoid const(RefCounted!T) completely.

I'm not really saying I disagree with that, but it's just not 
realistic. Which code would you rather write?

void foo(T)(const T t) {}
foo(myValue);

or:

void foo(T)(T t) if (isTailConst!T) {}
foo(myValue.tailConst);

The beauty of .headMutable is it generally doesn't affect user 
code. If we have to tell people not to use const(T) because its 
semantics are broken, we've failed.

Now, if at any point in your program you have an 
immutable(RefCounted!T), something's gone horribly wrong - 
basically all of the RefCounted's semantics break down when it's 
immutable, and any attempt at fixing it is undefined behavior. I 
think we can safely disregard the problems of 
immutable(RefCounted!T).

Once we've defined immutable(RefCounted!T) to be undefined 
behavior, suddenly casting from const(RefCounted!T) to 
RefCounted!(const(T)) is OK again.

--
   Simen