Purity, @safety, etc., in generic code

Zach the Mystic reachBUTMINUSTHISzach at gOOGLYmail.com
Tue Feb 19 23:59:01 PST 2013


On Wednesday, 20 February 2013 at 07:42:56 UTC, Zach the Mystic 
wrote:
> 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.

What would be nice is if the vtable could get its two functions, 
but have them both point to the same one in the end, to save 
space in the binary file. But I think the forward reference 
problem might interfere with that too (although, as I said, I 
don't fully understand it).


More information about the Digitalmars-d mailing list