Making RCSlice and DIP74 work with const and immutable

[H. S. Teoh via Digitalmars-d]

On Sun, Mar 01, 2015 at 03:47:36PM +0000, via Digitalmars-d wrote:
> On Sunday, 1 March 2015 at 15:08:47 UTC, H. S. Teoh wrote:
> >On Sun, Mar 01, 2015 at 01:43:44PM +0000, via Digitalmars-d wrote:
> >>On Sunday, 1 March 2015 at 06:42:02 UTC, H. S. Teoh wrote:
> >[...]
> >>>So then Const!MyClass is a modified version of MyClass where >the
> >>>data fields are const (similarly, we can define Immutable for the
> >>>analogous purpose) but the fields marked as metadata will >remain
> >>>mutable.
> >>>
> >>>Of course, this is just a crude first stab at the problem; >I'm
> >>>sure there's plenty of room for refinement to make it more usable,
> >>>>and to address some obvious roadblocks, like how to make MyClass
> >>>>>implicitly convertible to Const!MyClass, etc.. But it seems
> >>>>>likely that >D's template machinery can actually express this in
> >>>>>a way that >does not violate the guarantee of physical const.
> >>
> >>You still cannot access it through a const reference, though.
> >
> >The whole point is to use Const!T instead of const(T).
> 
> But that's intrusive! You can only apply it code you control, or at
> least you have to convince everyone to use it.

I don't see any other way of supporting logical const without violating
physical const in some way. As soon as const(T) means anything other
than const(T), you open up a hole in the type system and the const
guarantee becomes no longer a guarantee, but a mere advisory like C++
const.


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry