Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed

[James Dennett]

Frits van Bommel wrote:
> James Dennett wrote:
>> maXmo wrote:
>>>> we can write generic array operations by them, not relying on
>>>> Derived[]-to-Base[] conversions.
>>> but wouldn't templates bloat your code? I don't know
>>> how D deals with them but in C++ when you instantiate
>>> template with different parameters you get several instances of the
>>> template, all the templated code gets copied.
>>
>> Except when it doesn't, such as when an implementation
>> notices that the generated code is the same (such as
>> when the templated is instantiated over a number of
>> types whose representations and behavior at the level
>> of machine code is identical) and collapses them to a
>> single instance.
> 
> And as long as function pointers aren't compared[1]. 

Failure to respect that makes this "optimization" a bug
in one common implementation.

> Thought that
> behavior could be preserved by having multiple entry points into the
> same function[2].

Yes; that's the obvious solution, with a trivial runtime
impact traded off for reduced space.  (An alternative,
also with runtime cost, is that one implementation is
jumped to from others.  The cost can be higher in that
case, but is constant no matter how many callers there
are.)  The case of taking addresses is relatively rare,
however.

> Also, such folding will probably not work across object files[3], unless
> you implement it into the linker. AFAIK current linkers don't support
> this[4].
> 
> 
> [1]: They must presumably be different for different functions, right?
> [2]: A few nops at the beginning, entry points with just a jump, whatever.
> [3]: When compiling separately, at least.
> [4]: Except if you incorporate the entire machine code into the section
> name...

I've a feeling that this *is* implemented in the linker
in the one system that does it today -- but don't quote
me on that, as I've not checked in detail.

>> It's good to distinguish features that are *forced* by
>> a language design choice and those which depend on how
>> an implementation chooses to work.  (It's also good to
>> take into account how much work is involved in the
>> implementation of a feature; if it's too much, it likely
>> won't be done well.)
> 
> Indeed.

-- James