Do we need a time-out in D evolution?

[Thomas Kuehne]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

BCS schrieb am 2007-06-10:
> 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.

The most direct solution would be to ask for a Dv2 version of the closed
source lib. If there is sufficent demand it is very likely that the lib
is going to be ported rather sooner than later. User code might be inter
linkable. The real problem could be the runtime internals(including the GC).

In a sence this is the current GDC versus DMD issue on steroids. Currently
an object file generated by GDC can't be linked against one generated by DMD.
And no GDC and DMD aren't feature identical, thus closed source lib
providers already should have a flexible enough source to support
DMD + Phobos, DMD + Tango, GDC + GPhobos and GDC + Tango within one source
tree. Especiall considering that Dv2 is going to be - after some testing
ofcourse - the D mainline, adding Dv2 support to the mix shouldn't be too
difficult. 

Thomas

-----BEGIN PGP SIGNATURE-----

iQIVAwUBRm0DD7ZlboUnBhRKAQK2MQ//d/19rJJt7A26zRN88e2yQQZ/8HvrpDga
4HvI/eBcVpJh4yI/rTak3mN98OoiJ8O2Ht2rqQ+M9YvZksQZnpVa1t/m55FcWx/8
QTeefF7Ah7GJku1333j7jlC/xEGli5wyJPbJGkMVQ+fLuC8lDRfCL4XcHrdPfv7P
KJKuxhW4vibI1za007SySRdkHya59Dw97y52bi3VpXj/+q/cgjT9S+HvZHSgFe1s
FNIc+l6olZtRGzD5dDbGcF4siihzBuQt7Zm22by6Cb219227r8Oes7aIra1NSuP1
AV2tdPspZyCcz++fJYOjBmqY+Jb7f1RMNxEXwHWGZIxwDYvOfATggV+ftXviZVjk
IBiDk0FjDyajyVuh/XL2+mDPBu7h48PVNdn+KQ2cvcxAMw07wqA2zv/QjXdbdSrU
wyMVkhS6vzB71GkI1w8AtETQ7k06iDhUZxP+tAX2GDRYPKL33Ifi/Z9yT6AUqJ7O
O5WFu/5f9kFMxzYF33/IFEApXpjqzT5DIkfHYy+ii9GLfLLybb8frnIOSo5fYlUw
lUYQZjVeZDIuZvTZADL/sqvnJ/A25sddEPTgvmT+HlwCbqFWRQZIES1HuI7TRWw4
mGS9qFXkXXyAwCDHIStA9ipdzvAkEMbgmthKcn8R2HzrxkCOFwZonGbAMD6IaxUx
512PeQHmoAg=
=zJLt
-----END PGP SIGNATURE-----