Private imports and Objects

[helxi]

On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis 
wrote:
> On Thursday, November 30, 2017 06:29:43 helxi via 
> Digitalmars-d-learn wrote:
[]
> I don't understand the question. You're asking whether casting 
> from a base class to a derived class creates overhead? Or are 
> you asking whether having a base class for all classes creates 
> overhead? Or something else?
>
> Object exists primarily because D didn't originally have 
> templates, and when you don't have templates, having a single 
> base class is the only way to have a function accept any class, 
> and for something like a container, you'd pretty much be forced 
> to use void* without Object if you don't have templates. 
> However, once templates were added to D, the benefits of Object 
> were significantly reduced, and it's arguably not a 
> particularly good idea to be writing code that operates on 
> Object. However, it's far too late in the game to get rid of 
> Object.
>
> At one point, it was decided to remove Object's member 
> functions, because having them on Object needlessly locks in a 
> particular set of attributes for those functions, and if we did 
> that, then there really wouldn't be much reason to use Object 
> directly, but that change has never happened, and it's not 
> clear that it's going to happen, since there are a number of 
> technical issues that make it a bit of a pain to do 
> (particularly if we don't want to break a lot of code). One of 
> the bigger issues is that the AA implementation in druntime 
> needs to be templated so that it doesn't need to operate on 
> Object, and that's proven to be a bit of a challenge.
>
> https://issues.dlang.org/show_bug.cgi?id=9769 
> https://issues.dlang.org/show_bug.cgi?id=9770 
> https://issues.dlang.org/show_bug.cgi?id=9771 
> https://issues.dlang.org/show_bug.cgi?id=9772
>
> - Jonathan M Davis

I was actually referring to both. Override functions such as 
opCmp, opEquals, toString, toHash etc --wouldn't they be 
inherently expensive? I thought they are virtual functions. Also, 
with regards to casting, wouldn't this be an extra legwork? Both 
of these seem to be a performance handicap to me. But I'm no 
expert on this matter. Maybe the compiler optimises it away since 
normally you'd cast to a constant subclass.