Head Const

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 16 February 2016 at 16:27:54 UTC, Jonathan M Davis 
wrote:
> 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:

I don't think I understand the semantic difference.

Transitive immutability is mostly useless. You usually want at 
least to be able to have a back pointer to a mutable index so 
that you can move the object to another index. This is also not 
something you can prevent. I can simply have a global set of 
indices and refer to that global set through an index ID in the 
immutable object. That is equivalent to breaking immutable 
transitivity.

So... you cannot have transitive immutability if you allow global 
data structures. Then you would have to require "pure" functions 
everywhere.

I also don't see how a reinterpret cast to a negative offset can 
be a good solution. If you need that, then you have a strong sign 
that something important is missing in the type
system.  Where would this be allowed? Not in "pure" functions, 
for sure?


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

It shouldn't pose a problem for a system level language to hand 
memory access through a thread local pointer to another thread if 
need be, but not sure if I follow the argument.


>, and I'm opposed to introducing non-transitive
> const like Walter brought up with this thread. It's just not 
> worth the complexity.

But you do at the very least need a mechanism for triggering 
overloads on "const A&", "A&&" etc. C++ libraries tend to be 
heavily overloaded...