Head Const

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 16 February 2016 at 15:33:03 UTC, Jonathan M Davis 
wrote:
> const guarantees that the data will not be mutated via that 
> reference to the data. It guarantees nothing about other 
> references to that data. For that, you need immutable.

Yes, it's as weak as C++ const in most cases from an optimization 
POV.

In C (and some C++ compilers) you can say that there is no 
aliasing by using "restrict", so I guess what I want is something 
like "const restrict".

https://en.wikipedia.org/wiki/Restrict

> But as long as const guarantees that the data can't be mutated 
> via that reference, then there's plenty of code where the 
> programmer can look at it and know for sure that that data 
> isn't being mutated, because they know that the code in

When you are calling a function that is no-global-access "pure", 
yes.

> If casting away const and mutating is defined behavior, then 
> you lose that guarantee, and instead of knowing that some code 
> doesn't have access to a mutable reference to that data being 
> enough, you have to actually know what the code does to know 
> that it's not casting away const and mutating.

Yes, I agree that casting away const as is possible in C++ is 
bad. The only reasonable setting for doing so is when you call 
legacy functions that are not defined to be const, but 
implemented as such.

> Having @mutable would be better than allowing casting away 
> const and mutating to be defined behavior (at least when the 
> underlying data is mutable rather than immutable), because it 
> would at least restrict the data that can be mutated, and it 
> would guarantee that you don't accidentally mutate an immutable 
> variable (since it would make no sense to have a type with an 
> @mutable member be immutable, whereas if you're casting away 
> const, getting that right would be completely up to the 
> programmer).

Maybe I misunderstand, but I am likely to want an immutable 
object with a mutable field, e.g. ref-counted caching. You use a 
CAS instruction on the mutable ref-counter and share the data. 
Then you can flush the cache and release all objects that have a 
refcount of only 1 (the cache index pointer).

> But having @mutable would  still mean that you can't rely on a 
> const variable not being mutated when you pass it to a function 
> that you know doesn't have access to a mutable reference to the 
> same data. If you knew that no @mutable was involved, it would 
> be the same as now, but you'd have to know for sure that 
> @mutable was involved, and even if it isn't now, it could be 
> later after refactoring.

Well, yes, this is where you have to be very clear about what 
kind of semantics a struct is meant to have. I don't feel this is 
very clear in the current language.

To me the value of immutable is that fields that are immutable 
will remain immutable forever. Like for a key that is inserted 
into a hash table. You know that it cannot change so you never 
need to recompute the hash value.

Then I'd like to see a "limited time immutable", like the 
"restrict const" suggested above.

But apparently there are use-cases where you'd want to say "whole 
object is immutable" and other use-cases where you want to say 
"all non-forced-mutable fields are immutable".

> So, having @mutable would be far better than having it be 
> defined behavior to cast away const and mutate (assuming that 
> the underlying data is mutable rather than immutable), but 
> you're still losing out on guarantees that we have now.

Yes. But I think you could distinguish between what you specify 
and what you require. So you could specify "I only want wholly 
immutable things" in a function signature, and specify "this 
object is mostly immutable except for these mutable exceptions" 
when defining it.

So I think you can have both?