Persistent list

[Andrei Alexandrescu via Digitalmars-d]

On 11/15/2015 03:17 PM, Timon Gehr wrote:
> On 11/15/2015 08:57 PM, 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;
>> }
>> ...
>
>
> This is the exact exception he described i.e. "unless I have another,
> mutable reference to foo somewhere that bar somehow accessed."

Nope. He doesn't have a reference; the implementation has 
surreptitiously, without the caller's knowledge.

Big difference! That means the modular typechecker cannot make any 
assumption about the immutability of that object.

Let me repeat: const is already as weak as some fear it might be. 
(Immutable is fine.)

> (Also, 'bar' should be 'const'.)

Right.

>> In other words, you truly need access to the implementation of getFoo()
>> in order to claim anything about the changeability of stuff.
>
> No, e.g., make either 'getFoo' or 'bar' pure.

Well but it's not. Keep the goalposts where they are. This is about 
"const". I do agree that "pure const" may have other, stronger 
properties. But let's discuss "const" and what it can promise, or move 
over to a whole new topic of "pure const".

>> Note that I
>> could even afford to have getFoo() return const, so no need for the
>> caller to make it so!
>>
>> 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.
>> ...
>
> This is obviously true (it is what justifies the distinction between
> const and immutable in the first place), but this is not a way to
> justify making it weaker.

Weaker than what? I've just shown black on white it's not a guarantee of 
constant data. Today. With no compiler bugs in sight.

> This is all just moving in the direction of a
> setting where all structs/classes just prevent immutable construction
> and make all member functions const, and const becomes the new mutable.
> I don't see the point.

I don't understand this.


Andrei