Fully transitive const is not necessary

Fawzi Mohamed fmohamed at mac.com
Fri Apr 4 10:16:13 PDT 2008


I understant Steven proposal, and it is a nice proposal and it could 
work, and indeed it is nice to have a way out of the const, but I am 
terribly afraid of this.

Maybe I am wong (in this case please point out a pratical example where 
this is not the case), but what is the use of such a data?

The only use that I can imagine (if the object is really constant) are 
cache or performance related, so informations not really needed, but 
useful for improving the performance.

So naturally also "pure" functions would like to take advantage of it, 
or the usefulness of the whole is very diminished.
But then the cache has to be done *very* carefully to avoid curruptions 
due to multiple threads accessing the object...

It is possible but really not easy (and needs locking or atomic 
operations that probably will not be good for performance), so very 
likely it will be done badly and will lead to very subtle bugs.

I really think that the controlled and already studied ways to relax 
the const are "suspended evaluation", and "undefined settable value 
blocking on read".

I also think that indeed what walter wants is as guslay said

> A = B = C

because you never know (and for performance reasons do not want to 
know) if another thread is executing a g_not_pure on the same data on 
which a pure function is working.
You do not want to aquire locks before executing a pure function.

Fawzi

<guslay at gmail.com> said:

> Walter Bright Wrote:
> 
>> 
>> Logical const just utterly breaks the whole system.
> 
> 
> I think we had a different expectations about invariant and pure.
> 
> Do you believe that (A),
> 
>    invariant A a;
>    int x = f_pure(a);
>    g_not_pure(a); // potentially mutating mutable members of A
>    int y = f_pure(a);
>    int z = f_pure(a);
> 
> which is can be transformed without problem to (B),
> 
>    invariant A a;
>    int x = f_pure(a);
>    g_not_pure(a);
>    int y = f_pure(a);
>    int z = y;
> 
> MUST also be equivalent to (C) ?
> 
>    invariant A a;
>    int x = f_pure(a);
>    int y = x;
>    int z = x;
>    g_not_pure(a);
> 
> 
> A = B = C is only possible if invariant A as no mutable part. I agree. 
> Is this your position?
> 
> I was expecting a weaker pure model, where only A = B is true 
> (optimization based on purity only possible inside a contiguous block 
> of pure functions).
> 
> If this is correct then I understand your concerns against logical const.





More information about the Digitalmars-d mailing list