On Monday, 18 February 2013 at 07:46:24 UTC, kenji hara wrote:
Now, as for const, I don't think that the problem has been
solved yet. We
really need some sort of inferrence there, which is why a
number of months
ago
I created this enhancement request for inferring inout:
http://d.puremagic.com/issues/show_bug.cgi?id=8407
AFAIK though, no one's even looked at it, so I don't think
that it's had
any
effect as of yet. One of the compiler devs will need to take
it up for it
to
make it in.
I think const must not be inferred for member function, because
it affects
to the function overloading. For example, the const-ness for
class method
will be inferred from base class overridden method with current
compiler,
but it causes a serious problem.
http://d.puremagic.com/issues/show_bug.cgi?id=8366
Instead, you should declare two methods in generic code - one
is mutable,
and another is const/inout.
Kenji Hara
I'll say upfront that I don't understand this problem completely,
but I was trying to solve it anyway!
What bothers me is that the spec for 'inout' functions suggests
that they generate the same runtime code, so it seems weird that
there should have to be different vtable entries for the same
code.
Following that thought, perhaps 'inout' class member functions
could be treated specially in the case of classes. If the base
class defines a method using inout,
class A
{
bool foo(inout Object o) inout { return true; }
}
... it defines a single function in the vtable, which applies to
mutable, const, and immutable. If a subclass then defines a
mutable method, that function is added to the vtable for that
class and all descendent classes. It must be defined with
override, despite that it actually creates a new function
underneath:
class B : A
{
override bool foo(Object o) { return false; }
}
I am in the position of someone who knows he doesn't know
everything he needs to know, but who doesn't want a good idea to
go unmentioned either. Do you think this idea has merit?
