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.


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


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


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