Persistent list

[Jonathan M Davis via Digitalmars-d]

On Sunday, 15 November 2015 at 21:45:08 UTC, Dicebot wrote:
> On Sunday, 15 November 2015 at 21:00:40 UTC, Andrei 
> Alexandrescu wrote:
>> Passing arguments to functions that aren't supposed to change 
>> the containers. -- Andrei
>
> For that you don't need to mutate neither allocator nor RC 
> (unless that const argument is actually leaked from inside the 
> function to somewhere else - terrible, terrible thing to do). 
> So strict physical const should suffice.

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). But anything that would require that a range be 
able to mutate its associated container even for bookkeeping 
purposes wouldn't work with const. Certainly, any case where you 
want to do something like keep removed elements around 
specifically for a range and then destroy/free them when no range 
refers to them won't work with const.

Physical const works fantastically when you just want to pass 
something in and get a result. As soon as something needs to be 
stored as const or if you start trying to do fancy stuff like 
managing memory inside of an object, you quickly run into cases 
that don't work with it. I think that we can choose to live with 
that, but it _does_ mean that there are useful idioms that will 
be impossible with const, and ultimately, that probably means 
that const won't be used much - particularly when dealing with 
user-defined types.

And since you seem to think that it should be fine to cast away 
const and mutate when the object is actually mutable, I don't 
really see what objection you can have here as long as it's sure 
that PersistentList isn't immutable. Andrei's @mutable proposal 
would fix that, but even without that, I expect that we could 
force it by declaring an immutable constructor with no body and 
declaring opCast such that it doesn't work with immutable (though 
that's arguably abusing 
https://issues.dlang.org/show_bug.cgi?id=5747 ).

Regardless, I think that it's quite clear that certain idioms 
simply do not work with physical const, and there's been 
complaining about that for years. The only real question here is 
whether those idioms are worth enough to lose out on physical 
const. The answer up until now has always been no (at least from 
Walter), but since Andrei is now hitting this himself rather than 
seeing others complain about it, he clearly views it as a problem 
in a way that he didn't before, so that may result in him 
changing Walter's mind.

- Jonathan M Davis