How to break const

[Artur Skawina]

On 06/19/12 09:59, deadalnix wrote:
> Le 19/06/2012 00:16, Artur Skawina a écrit :
>> On 06/18/12 23:08, deadalnix wrote:
>>> Le 18/06/2012 09:14, Mehrdad a écrit :
>>>> Okay, how about this? http://ideone.com/VMlzS
>>>>
>>>> Does this break const?
>>>>
>>>>
>>>> import std.stdio;
>>>> class S
>>>> {
>>>> this(int a)
>>>> {
>>>> this.a = a;
>>>> this.increment = { this.a++; };
>>>> }
>>>> int a;
>>>> void delegate() increment;
>>>> void oops() const { this.increment(); }
>>>> }
>>>> void main()
>>>> {
>>>> auto c = new const(S)(0);
>>>> writeln(c.a);
>>>> c.oops();
>>>> writeln(c.a);
>>>> }
>>>
>>> Depending on how it is specified, I think you should either :
>>>   - get an error when constructing c, because S isn't « constable ». (delegate type cannot be consted, but can be unconsted safely).
>>>   - get an error when you try to call increment in oops, because the delegate type can't ensure the constness of the operation.
>>>
>>
>> I'm afraid that:
>>
>> - Banning implicit mutable->const conversions would do far more harm,
>>    so this would not be a good solution to the problem.
>> - Requiring that the type of the delegate "ensure the constness" would
>>    be far too restrictive. (the question would be: "Is any data reachable
>>    via 'this' also reachable through the delegates context pointer?" and
>>    every such delegate would of course need to be "pure" [1].
>>
>> [This isn't *just* about the above example, you get the same problems
>>   when a const object isn't created but received from somewhere.]
>>
>> artur
>>
>> [1] which is a misnomer.
> 
> Due to D concept of weak purity, this doesn't ensure the required what we need here.

Actually, it does - if it can be proved that the delegate can't alter the object
via the context pointer (eg because whatever it points to is not mutable) then
even D's "pure" is enough. Because the delegate would need to be passed a mutable
ref to be able to alter the object, which then could hardly be constructed as
"breaking" constness.

But such a limit (const/immutable context) would be a problem for the cases where
the delegate needs to alter some state (like export the result of some operation),
but does _not_ modify the object it's embedded in. Note that the current object may
very well be reachable (and mutable) from the delegate - but at some point you have
to trust the programmer. Sure, fixing this hole would be great, but /how/ - w/o
incurring unacceptable collateral damage?

> It is possible to get the error when trying to call the delegate instead of preventing to make it const, as I said in the post you quote. It is probably a better solution.

Any delegate?


On 06/19/12 10:18, Don Clugston wrote:
> On 18/06/12 17:00, Artur Skawina wrote:
>> D's "weak pure" can help; I just don't like the redefinition of the term
>> "purity"; another name for "weak purity" would be better.
> 
> So would I. Can you think of one?
> It was the best name I could come up with, given that the 'pure' was the keyword.
> We want a word that means 'no hidden state'.

No, I can't think of an appropriate term either, from the current keyword list.
Plus, inventing yet another one just leads to function qualifier hell. But, as it
is, you're not able to mark a function as ("stronly") pure if it takes const args
w/o resorting to pragmas. Immutable data is not always the solution. And having
almost everything marked as "pure", when all it does is it prevents global/static
accesses and does not influence codegen in any way, only creates confusion.

artur