On Monday, 16 November 2015 at 08:18:55 UTC, Jonathan M Davis
wrote:
And actually, this gives me an interesting thought. Does making
casting away const and mutating defined behavior give us a way
to fix our postblit problem? I could see an argument that
postblits should be completely unnecessary for immutable values
(because you shouldn't need to avoid stuff like sharing
references when it's immutable), which could mean that we could
change it so that immutable structs values didn't trigger a
postblit and thus worked fine as-is, and that would fix the
problem with postblits and immutable. And if casting away const
and mutating is legit, then it should be possible to treat the
struct itself as mutable (or at least tail-const) within the
postblit constructor, in which case it's then actually possible
to have postblit constructor that works with const, whereas
right now, we can't have it, because it would violate const to
mutate the newly blitted, const struct.
So, if this really fixes our postblit problem, it might be
worth it just for that. As it stands, postblit constuctors tend
to have to be avoided in many cases because of how badly they
interact with const and immutable.
Actually, with regards to immutable, it looks like you can
already copy immutable objects with postblit constructors. You
just can't copy it and get a mutable value out of it. But copying
and creating another immutable value or a const value both work
just fine. So, it looks like the only thing we're missing with
regards to immutable and postblits is the ability to get a
mutable copy, but that's not really much of a loss as far as I
can think of at the moment.
So, really it's just the issue with const and postblit that
really needs fixing, and allowing the mutation of const to be
defined behavior when the underlying object isn't immutable could
give us the out we need to fix that problem.
- Jonathan M Davis
