Persistent list

[Andrei Alexandrescu via Digitalmars-d]

On 11/15/15 8:29 PM, Timon Gehr wrote:
> On 11/15/2015 10:06 PM, Andrei Alexandrescu wrote:
>> ...
>> 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".
>> ...
>
> "pure" is independent of "const" at the moment. So what you want to
> discuss is "const" in impure method signatures. Fine.
>
> In any case, consider that you might at some point be asked to explain
> why a const List is a good thing to want but a const pure List isn't.
>
>>>> 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.
>
> In one particular case.
>
> import package.module : foo, bar, baz, fun;
>
> final class C{
>      int x;
>      private this(int x){ this.x=x; }
> }
>
> void main(){
>      auto c = new C(2);
>      foo(c); // void foo(const C c);
>      bar();  // impure
>      baz();  // impure
>      fun(c.x); // this read of c.x can be optimized away under current
> semantics, not under the new ones
> }

Actually, you're wrong here. Typechecking main() does not take C's 
constructor's body into consideration, just the signature. So all the 
compiler knows about C whilst typechecking main() is:

final class C {
   int x;
   private this(int x);
}

What could happen (implausibly, but typechecking must be conservative) 
is that C's constructor may communicate with foo's package through a 
global, e.g. setting a global int* with the address of x. Then clearly 
the read of c.x cannot be optimized away today.

It's possible a class of examples can be found, but this is not one.

>> Today. With no compiler bugs in sight.
>> ...
>
> Do you mean, even ignoring compiler bugs?
>
>>> 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.
>> ...
>
> const is transitive and contagious. Make casting away const legal and
> spuriously require const in some places in the library, and you will
> have created a quite large incentive to use the now legal casts in a way
> that some will consider unprincipled.

Yah, I agree with that argument. Probably @mutable is a more principled 
way to go about things.


Andrei