Purity, @safety, etc., in generic code

[Zach the Mystic]

On Wednesday, 20 February 2013 at 06:00:02 UTC, deadalnix wrote:
> On Tuesday, 19 February 2013 at 16:57:33 UTC, Zach the Mystic
>> I have no reason not to trust your great experience on this 
>> matter. Is syntax sugar a possible solution?
>>
>> class A
>> {
>>    bool foo(in Object o) inout { return true; }
>> }
>>
>> ... lowers to:
>>
>> class A
>> {
>>    bool foo(in Object o) { return true; }
>>    bool foo(in Object o) const { return true; }
>> }
>>
>> Or would that lead to extensive problems of its own?
>
> The problem is now that you may overload one or the other 
> function in derived classes. Such a surprising behavior is not 
> acceptable IMO.

It's not that surprising, IMO. If only one is defined in the base 
class, 'override' would give an error:

class A
{
   bool foo(in Object o) { return true; }
}

class B : A
{
   // This:
   override bool foo(in Object o) inout { return false; }
   // ...would translate to this:
   override bool foo(in Object o) { return false; } // Pass
   override bool foo(in Object o) const { return false; } // Error
}

The 'const', when overridden, would naturally give an error, 
since it's not overriding anything. If there are already two 
defined in the base, then the new overridden 'inout' is exactly 
what you want, two new functions for the derived. If there's 
nothing in the base, then 'override' won't work for either of the 
functions it declares.

> As discussed previously, I really wonder hy a const and non 
> const version of a function can exists in a first place. What 
> problem does it solve that isn't better solved by inout ?

I'm taking it as given that Kenji Hara knows what he's talking 
about when he says that a single function is no good. I don't 
understand it fully, but I'm trying to work within the context of 
what he says. I think he doesn't want to disturb the way the 
vtable is built, and inferring const seems to force the addition 
of another function into the table, but only when it is used, and 
so you can't tell what the vtable is supposed to look like until 
you've processed all calls to the const-inferring function. And 
to make the two do exactly the same thing is asking for trouble 
if you end up overloading one - then you could break const-ness 
by only overloading the mutable one in a derived class. The 
forward referencing problem is beyond my comprehension at the 
moment, but Hara is convinced its a fatal flaw in the system.