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).
