From the changelog:
> 0.72
> - Implicit conversions of B[] to A[] are now allowed if B is derived from A.
> 0.73
> - Implicit conversions of B[] to A[] are no longer allowed if B is derived from A.
>   Gaping type safety holes are the reason.

In the latest D 1.0, this kind of implicit conversion seems to be revived. Were there any disucussions on the revival of this feature?

Im my understanding, such implicit conversion is a bad thing,
as Daniel Yokomiso has pointed out in the thread of DMD 0.72 release:

  http://www.digitalmars.com/d/archives/17039.html

Java does have such implicit conversions reluctantly, but it is only
because Java <=1.4 had lacked generics (and therefore lacked the power to
write generic array operations.) On the other hand, D has templates, so
we can write generic array operations by them, not relying on Derived[]-to-Base[] conversions.

What do you think?

> 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.

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.

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.)

-- James

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]. Thought that behavior could be preserved by having multiple entry points into the same function[2].
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...

> 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.

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

James Dennett wrote:
> 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.

Doesn't implementing it in the linker make it language-neutral? Then it's not really related to D except in a very indirect manner, meaning this is probably not the best place to discuss this.
(Unless you plan to implement a new linker in D :p)

Frits van Bommel wrote:
> James Dennett wrote:
>> 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.
> 
> Doesn't implementing it in the linker make it language-neutral?

Largely, yes.

> Then it's not really related to D except in a very
> indirect manner, meaning this is probably not the
> best place to discuss this.

Except that an unfortunate proportion of thought about
the evolution of D is driven by misunderstandings about
the corresponding decisions relating to C++ and their
impact.  The "templates cause code bloat" mantra is
popular, and is too simplistic to be a good approximation
to the truth.  "Templates can vastly reduce the amount
of source code that has to be written and maintained,
and can make the code that is present very readable,
but can come at a cost in terms of implementation
complexity, and can contribute to bloated binaries
unless used sensibly and with quality implementations"
is a little too long to make a good sound bite though.

> (Unless you plan to implement a new linker in D :p)

Not today ;)

-- James

James Dennett wrote:
> Frits van Bommel wrote:
>> James Dennett wrote:
>>> 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.
>> Doesn't implementing it in the linker make it language-neutral?
> 
> Largely, yes.
> 
>> Then it's not really related to D except in a very
>> indirect manner, meaning this is probably not the
>> best place to discuss this.
> 
> Except that an unfortunate proportion of thought about
> the evolution of D is driven by misunderstandings about
> the corresponding decisions relating to C++ and their
> impact.

Well, there's that :p.

>> (Unless you plan to implement a new linker in D :p)
> 
> Not today ;)

Me neither ;).