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