Persistent list

[Jonathan M Davis via Digitalmars-d]

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