Arbitrary abbreviations in phobos considered ridiculous

[Nick Sabalausky]

"Daniel Murphy" <yebblies at nospamgmail.com> wrote in message 
news:jjhcj8$25sv$1 at digitalmars.com...
> "Nick Sabalausky" <a at a.a> wrote in message 
> news:jjh9uh$1vto$1 at digitalmars.com...
>>
>> My understanding is that the *only* thing preventing vitrual template 
>> functions is the possibility of pre-compiled closed-source static libs. 
>> Which is why I've long been in favor of allowing vitrual template 
>> functions *as long as* there's no closed-source static libs preventing 
>> it. Why should OSS have to pay costs that only apply to closed source?
>>
>
> That's not really it...
>
> The problem is that vtables contain every virtual function of a class - 
> and if you instantiate a template function with a new type, it would 
> require a new vtable entry.  Therefore you need to know how every template 
> function in every derived class is instantiated before you can build the 
> base class vtable.  This doesn't work with D's compilation model.
>

Right, but when I tell something like rdmd to pass all my files into DMD, 
then DMD *does* have all the information needed. I understand that it can't 
be done in *all* build setups, but it would seem to be possible in many 
build setups, so why should *all* projects suffer when really only *some* 
projects have to have that limitation? That's what I've never understood.

>>
>> Now, as for whether or not D actually *does* omit the vtable entry for 
>> non-override finals, I wouldn't know. Although I seem to vaguely remember 
>> doing optimizations once that seemed to imply it did. If that's so, I 
>> don't know whether its guaranteed per D spec or just 
>> implementation-defined. A UFCS approach would definitely be guaranteed 
>> not to affect the vtable, of course.
>>
>
> D (dmd) does not create a vtable entry for final functions that don't 
> override anything.  It's in the frontend, so it should be the same for all 
> the d compilers.

I see. Thanks.