Fully transitive const is not necessary

[Bill Baxter]

Janice Caron wrote:
> On 01/04/2008, guslay <guslay at gmail.com> wrote:

>>  -= Const != thread-safe =-
>>
>>  A method with potential side effects is not implicitly thread-safe.
> 
> Again with the obvious. Is there any point to this? Are you somehow
> suggesting that anyone on this newsgroup believes otherwise?
> 
> 
>>  -= Const is not the key to functional programming =-
> 
> Yes it is. But const is /part/ of the solution, not the /whole/ of the
> solution. Saying "const is not the key to functional programming" is a
> bit like saying "wheels are not the key to making cars". Well, it's
> true that wheels aren't /enough/ to make a car - an engine would help,
> for as start - but they do matter. It would be a tough job making a
> car without wheels. And likewise it would be a tough job making
> functional programming work without (transitive) const.

Analogies can be use to prove a lot of untrue things.  Legs are used by 
pretty much all creatures on the planet to get from point A to point B, 
so it is obvious that a man-made vehicle will also certainly require 
legs.  Maybe const is like legs.

>>  This concept is not yet into place, but I will define it has a method that only call other pure functions, and performs read-only operation on its class members and static/global data.
> 
> INCORRECT. A pure function cannot read static or global data, period.

Unless the data is invariant.  Shouldn't be a problem then.


>> Allowing this would be desirable.
>>
>>    class MyMutableClass
>>    {
>>       private         int normal_part;
>>       private mutable int mutable_part;
>>
>>       public int const lazyGetter();
>>    }
>>
>>    const MyMutableClass obj = new MyMutableClass;
> 
> The bottom line is that any class which is not /truly/ const, (as in
> physically, not merely logically), cannot be passed to any function
> which modifies the mutable parts, and simultaneously stay thread-safe.


>>  If not, people will find a way to hack around it with ugly tricks.
> 
> And their code won't be thread-safe.

And const will not have prevented it.  So what use was its transitivity?

>>  -= Allowing mutable members does not break or weaken the const model =-
> 
> I'm afraid it does. A type with mutable members can never be cast -
> either implicitly or explicitly - to fully const. That breaks
> everything.

But a type that depends on globals *can* be made fully const.  So why 
doesn't that break everything?

>>  What mutable does is allowing finer-grained control over the powerful const system. It does not weaken it, it controls its scope. Those are orthogonal issues (as far as I have yet to see an instance where having half the fields of an object const, instead of all the fields of the object, limits anything in any way).
> 
> Really?
> 
>     class C
>     {
>         int x;
>         mutable int y; // just pretend this is legal
>     }
> 
>     void f(const(C) c)
>     {
>         int temp = y;
>         y = temp + 1;
>     }
> 
> Now imagine two threads calling f simultaneously with the same c.
> Imagine a thread switch occurs between the two statements.

Now imagine instead of mutable int it's static int[C].  It's the same 
loophole.


>>  b) Mutable members are allowed. The object is passed as const. The caller can be confident that the internal state of the object will not be modified beyond the intention of the class designer.
> 
> ...or it might be screwed up entirely as a result of a threading conflict.

As would also be the case with the globals loophole.

Would think and write more, but gotta go now.

--bb