Do we need a time-out in D evolution?

[BCS]

Reply to Thomas,

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> BCS schrieb am 2007-06-09:
> 
>> Reply to Walter,
>> 
[...]
>> Well in that case I hope we'll get it when D2.0 comes out of beta.
>> (or maybe alpha)
>> 
>> Aside:
>> 
>> This sort of plays into a thought I had as to how D might be able to
>> avoid the mess that C++ seems to have gotten into. How about if each
>> major version of D is not required to be backwards comparable with
>> the last version. Where possible the extern(D<ver>) will be provided
>> for backwards (and maybe forwards) compatibility.  However If code
>> can't be mapped automatically, then it isn't directly callable and
>> that is assumed to be the cost of keeping a clean language.
>> 
> For some modules like std.math supporting Dv1 and Dv2 at the same time
> is most likely not difficult, however for the "rest" ...
> 
> My experience with Flectioned is that supporting multiple runtime
> libraries(GPhobos, Phobos, Tango) in D - or in the above case
> versions - can be a real pain. Supporting a Dv1-Dv2-mix in one
> binary might be possible (depends on how the overload rules change)
> but would require a lot of work with very little reward. The nice part
> about the Dv1 -> Dv2 change is that the vast majority of problems are
> going to be triggered at compile time (exception: some casts and
> assembler).
> In general I'm against an "extern(D<ver>)". In some isolated cases it
> might be useful however usually a feature test instead of a version
> test is going to be less bug prone.
> 

What about cases where someone ships a Dv1 closed source lib and I need to 
link it with my app that uses Dv2? It would be nice to be able to link such 
stuff together at least as well as D links to C. I wouldn't mind having a 
few corner cases where their is calling signature that can't be used from 
one to the other, but in the main, I expect that stuff will be inter linkable.

p.s. I am NOT thinking about being able to do direct import of Dv1 code by 
Dv2 code. I would expect that some sort of header files would be built that 
looks a lot like the stuff under std.c.