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