How to break const

[deadalnix]

Le 18/06/2012 09:58, Jonathan M Davis a écrit :
> On Monday, June 18, 2012 08:19:55 Mehrdad wrote:
>> On Monday, 18 June 2012 at 06:14:22 UTC, Matthias Walter wrote:
>>> Its not, that a const method cannot modify an object, it just
>>> ensures that the const method cannot modify the object *by
>>> using the this-pointer*.
>>
>> I see...
>>
>>
>> So that means you /can't/ tell something just by looking at a
>> part of the code, right?
>>
>> (Just mentioning this since this idea seemed to be emphasized a
>> lot by D.)
>
> You can if the function is pure as well, because then that delegate would not
> be legal. For instance, this code
>
> import std.stdio;
>
> struct Const
> {
>          this(void delegate() pure increment)
>          { this.increment = increment; }
>          int a;
>          void delegate() pure increment;
>          void oops() const pure { this.increment(); }
> }
>
> void main()
> {
>          Const c;
>          c = Const({ c.a++; });
>          writeln(c.a);
>          c.oops();
>          writeln(c.a);
> }
>
>
> fails to compile, giving this error:
>
> q.d(15): Error: constructor q.Const.this (void delegate() pure increment) is
> not callable using argument types (void delegate() nothrow @safe)
>
> All const guarantees is that the object isn't altered through the const
> reference/pointer (which in the case of a const function is this). That's
> powerful, but it needs pure as well to really be able to just glance at it and
> know that it's not altering your object.
>
> If you want an extreme exampl. you could create an object whose entire state
> was held in a global variable, then the fact that the this pointer was const
> wouldn't mean much. But if the member functions were pure, then you couldn't
> access that global variable, and so that externalization of the state wouldn't
> work, and you'd be guaranteed that the const function didn't alter your object
> (as long as none of the arguments to that const function held a reference or
> pointer to that object anyway (though that's a fairly abnormal thing to do) -
> only strong purity absolutely guarantees that your object isn't being
> altered).
>
> - Jonathan M Davis

It would be true if the delegate wasn't stored in c. For instance, it is 
true if the delegate is passed as oops argument.

But in our case, the type system is broken. See explanations in other 
posts I've made in this thread.