How to break const

deadalnix deadalnix at gmail.com
Mon Jun 18 08:27:47 PDT 2012


Le 18/06/2012 17:23, Timon Gehr a écrit :
> On 06/18/2012 05:13 PM, deadalnix wrote:
>> Le 18/06/2012 16:55, Mehrdad a écrit :
>>> On Monday, 18 June 2012 at 14:48:37 UTC, deadalnix wrote:
>>>> Le 18/06/2012 16:44, Mehrdad a écrit :
>>>>> Interesting, making the delegate `pure' doesn't change anything
>>>>> either.
>>>>>
>>>>> So 'pure' doesn't let you "infer something just by looking at the code
>>>>> either", right?
>>>>
>>>> It does ! It tell you that the function have no side effect, and that
>>>> the function called with identical arguments will return identical
>>>> results.
>>>>
>>>> pure will not ensure constness or immutability. const and immutable
>>>> are made for that.
>>>>
>>>> The fact that D decouple purity and immutability is a very nice design
>>>> decision and is explained nicely here :
>>>> http://klickverbot.at/blog/2012/05/purity-in-d/
>>>
>>>
>>>
>>> Identical calls giving identical results? What?
>>>
>>>
>>> import std.stdio;
>>> struct S
>>> {
>>> this(int a)
>>> {
>>> this.a = a;
>>> this.increment = { return this.a++; };
>>> }
>>> int a;
>>> int delegate() pure increment;
>>> auto oops() const { return this.increment(); }
>>> }
>>> void main()
>>> {
>>> auto c = immutable(S)(0);
>>> writeln(c.oops()); // 0
>>> writeln(c.oops()); // 1
>>> writeln(c.oops()); // 2
>>> writeln(c.oops()); // 3
>>> writeln(c.oops()); // 4
>>> writeln(c.oops()); // 5
>>> }
>>
>> They are not call with the same parameters. The hidden parameter have
>> changed (I know this is tricky).
>
> The whole problem is that the hidden parameter has changed. It is
> immutable!

As said, this is effectively a const/immutable issue. Not a purity issue.

I'm not claiming that this code is fine, just explaining that the code 
is fine in regard to purity.


More information about the Digitalmars-d mailing list