www.digitalmars.com         C & C++   DMDScript  

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

reply Kan <ycgdqbttbvpw mailinator.com> writes:
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?
Jan 29 2007
parent reply maXmo <terranium yandex.ru> writes:
 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.
Jan 30 2007
parent reply James Dennett <jdennett acm.org> writes:
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
Jan 30 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
James Dennett wrote:
 maXmo wrote:
 we can write generic array operations by them, not relying on
Derived[]-to-Base[] conversions.

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.
Jan 30 2007
parent reply James Dennett <jdennett acm.org> writes:
Frits van Bommel wrote:
 James Dennett wrote:
 maXmo wrote:
 we can write generic array operations by them, not relying on
 Derived[]-to-Base[] conversions.

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
Jan 30 2007
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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)
Jan 30 2007
parent reply James Dennett <jdennett acm.org> writes:
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
Jan 30 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.


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 ;).
Jan 30 2007