Head Const

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 16 February 2016 at 16:01:26 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 16 February 2016 at 15:33:03 UTC, Jonathan M Davis 
> wrote:
>> 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?

const and immutable are transitive. This is particularly critical 
with immutable, which is implicitly shared. Having portions of an 
immutable object be mutable wouldn't play nicely at all with how 
immutable works and would complicate things considerably. Andrei 
recently posted about possibly having a reference count be in the 
memory next to an immutable object but not having it in the 
object itself, and that might work:

http://forum.dlang.org/post/n9larg$23c9$1@digitalmars.com

But I really don't think that getting rid of transivity is going 
to fly for immutable (e.g. it's not like you can share part of 
object across threads and have part of it be thread-local), and 
I'm opposed to introducing non-transitive const like Walter 
brought up with this thread. It's just not worth the complexity.

- Jonathan M Davis