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
