Persistent list

[Jonathan M Davis via Digitalmars-d]

On Sunday, 15 November 2015 at 19:57:12 UTC, Andrei Alexandrescu 
wrote:
> On 11/15/2015 01:50 PM, Jonathan M Davis wrote:
>> On Sunday, 15 November 2015 at 18:09:15 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 11/15/2015 01:00 PM, Jonathan M Davis wrote:
>>>> Basically, we have to decide between having physical const 
>>>> with the
>>>> guarantees that it provides
>>>
>>> We have that - it's immutable. -- Andrei
>>
>> Yes and no. As it stands, I can know that
>>
>> const foo = getFoo();
>> foo.bar();
>>
>> won't mutate foo unless I have another, mutable reference to 
>> foo
>> somewhere that bar somehow accessed.
>
> That is an illusion, and we need to internalize that. Consider:
>
> // inside some module
> struct T
> {
>   int[] data;
>   void bar()
>   {
>     // look, ma, no hands
>     g_data[1]++;
>   }
> }
> static int[] g_data;
> const(T) getFoo()
> {
>   T result;
>   result.data = g_data = [1, 2, 3];
>   return result;
> }
>
> In other words, you truly need access to the implementation of 
> getFoo() in order to claim anything about the changeability of 
> stuff. Note that I could even afford to have getFoo() return 
> const, so no need for the caller to make it so!

Which is why I brought up pure. If either getFoo or bar is pure, 
then your backdoor doesn't work. Yes, without pure, globals work 
as a backdoor, but technically, they do that with immutable too, 
since you can put the entire state of the object outside of the 
object using globals.

> With immutable, it's all cool. Immutable data is truly 
> immutable, and that can be counted on. But const, even today, 
> cannot be assumed to be as strong.

No, const is not as strong as immutable. But my point is that 
as-is const still provides some guarantees about physical 
constness. And particularly when it's combined with pure, there 
are a lot of cases where you can rely on a const object not being 
mutated unless the programmer violates the type system. Contrast 
that with C++ where pretty much any function could choose to cast 
away const and mutate an object, making the const attribute 
essentially meaningless in principle. In practice, programmers 
are obviously better behaved than that, but it means that in D 
right now, const does provide actual compiler guarantees (even if 
they're not as strong as those for immutable), whereas in C++ it 
really only prevents accidental mutation.

If we go the route of making casting away const and mutating 
defined behavior (and possible adding something like @mutable), 
then what we'll end up with is a transitive version of C++'s 
const, and that definitely provides worse guarantees than we have 
now. So, we would be losing something if we made that change.

That being said, const as-is _is_ very restrictive, and a number 
of idioms are completely incompatible with it, and that sucks. 
But we've known that for some time, and the answer has generally 
been to either not use those idioms or to not use const - which 
unfortunately does mean that const often can't be used (and a 
container that needs to do fancy stuff with its internals is 
probably a prime place where it can't be used).

So, I'm not necessarily against changing how const works. It _is_ 
restrictive to the point of being impractical in a lot of code. 
But if we make such a change, we _will_ be losing out on the kind 
of compiler guarantees that Walter has been harping on for ages - 
how C++'s const is pretty much useless since it doesn't really 
guarantee anything, whereas D's const does provide compiler 
guarantees because it can't be legally cast away and mutated. And 
you don't seem to see that (at least based on what you've been 
saying).

There is a tradeoff to be made here. We've been choosing one side 
of that tradeoff for years now - the side that C++ didn't choose. 
Maybe we made the wrong choice and should switch sides. But it is 
a tradeoff, not a clear-cut decision.

- Jonathan M Davis