Purity, @safety, etc., in generic code
Zach the Mystic
reachBUTMINUSTHISzach at gOOGLYmail.com
Sat Feb 23 07:57:24 PST 2013
On Saturday, 23 February 2013 at 06:06:46 UTC, deadalnix wrote:
> On Friday, 22 February 2013 at 18:55:58 UTC, kenji hara wrote:
>> No, const/inout overload does not intend to solve 'method
>> hiding' problem.
>>
>> To clarify the situation, I try to explain.
>>
>> class A {
>> void foo() {}
>> void foo() const {}
>> }
>>
>
> You missed the important part. I'm talking about overload, not
> override. IE, not method hiding.
>
> What you have in class A here is useful for use cases that are
> now solved by inout (getting ranges/iterator from collection
> for instance).
To my mind the tradeoff underlying this whole issue is between
the principle of Don't Repeat Yourself (i.e. by writing two
identical functions), and the possible performance gains of a
mechanism which permitted only one function and one vtable entry
at runtime. But I think the latter are negligible. Making the
vtable contain two entries instead of one seems negligible in
terms of performance loss. If it is possible to have them point
to the same function, then there will be no executable bloat. I'm
pretty sure it's technically sound to allow this. I don't see why
it would be hard to implement either.
So my thinking was, if 'inout' solves the DRY problem in normal
code, but class inheritance makes it complicated when dealing
with classes, why can't it just create one function and two
different vtable entries which point to it?
More information about the Digitalmars-d
mailing list