Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
January 29, 2007 Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
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? |
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kan | > 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.
|
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to maXmo | 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
|
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Dennett | 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. |
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frits van Bommel | 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 |
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Dennett | 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)
|
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to Frits van Bommel | 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 |
January 30, 2007 Re: Suggestion: Implicit Derived[]-to-Base[] conversions should be disallowed | ||||
---|---|---|---|---|
| ||||
Posted in reply to James Dennett | 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 ;). |
Copyright © 1999-2021 by the D Language Foundation