On 26/08/2010 02:25, bearophile wrote:
Jonathan M Davis
If D2's user base really increases like we'd like it to (and TDPL should help a
lot with
that), it's going to cost users a lot more when backwards compatability is
broken.
This is why I don't like a lot the current work done for the 64 bit
implementation. D2 has some design problems (I don't call them 'enhancement
requests') that if you want to fix may require to break backward compatibility
(they are things that can't just be added to the D2 language), few months ago I
have listed about ten of them here (and I think Walter did just ignore them),
and probably few more are present (and one or two of them in the meantime have
officially become 'things to fix', like the syntax for array ops that I think
now officially requires obligatory [], this was one of the things in my list of
little breaking changes). I'd like those problems to be fixed (or specs to take
them in account, even if the compiler implementation isn't yet up to date to
them) before people start using D2 and breaking backwards compatibility becomes
a pain. Otherwise they risk never being fixed.
Implementation matters come after design matters if you impose the constraint
of keeping backwards compatibility.
Bye,
bearophile
I don't see how "fixing design problems that [..] break backward
compatibility" is that much of an issue for the 64 bit implementation.
Unless it's a really big design change (which then I would doubt would
be accepted), what kind of D design changes would really invalidate a
significant amount of work done on a 64bit compiler backend implementation?
--
Bruno Medeiros - Software Engineer
