Persistent list

[Jonathan M Davis via Digitalmars-d]

On Monday, 16 November 2015 at 06:36:31 UTC, rsw0x wrote:
> On Monday, 16 November 2015 at 06:24:05 UTC, Jonathan M Davis 
> wrote:
>> On Sunday, 15 November 2015 at 21:45:08 UTC, Dicebot wrote:
>>> [...]
>>
>> Except that what if the container is passed to something that 
>> keeps it around? The ref-count would need to at least be 
>> incremented when passing it, and if the container were passed 
>> around enough, it could potentially need to be incremented a 
>> lot.
>>
>> Ranges are potentially another big issue. As I understand it, 
>> there have already been issues with const and ranges with 
>> std.container.Array, because some of the fancy stuff that it 
>> does internally really doesn't work with const (though maybe I 
>> misunderstood).
>
> this has a lot to do with const being virtually useless with 
> structs

I'd say that there are two things about const which apply to 
structs which don't apply to classes which make const with 
structs bad. Stuff like having const member functions or having 
const values isn't necessarily any more of a problem with structs 
than it is with classes. What _is_ problematic is

1. const member variables (because they essentially force the 
whole struct to be treated as const even though it isn't - e.g. 
assignment doesn't work)

2. postblits don't work with const or immutable (so if you need a 
postblit, your struct really doesn't work with const or immutable)

Beyond that, const with structs is pretty much the same as it 
with classes. It's definitely restrictive, but not useless.

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.

- Jonathan M Davis