Breaking backwards compatiblity

[Sean Cavanaugh]

On 3/10/2012 3:49 PM, bearophile wrote:
> Walter:
>
>> I'm talking about the name change. It's far and away the most common thing I
>> have to edit when moving code from D1<=>  D2.
>
> We need good/better ways to manage Change and make it faster and less painful, instead of refusing almost all change right now.
> Things like more fine-graded deprecation abilities, smarter error messages in libraries that suggest how to fix the code, tools that update the code (py2to3 or the Go language tool to update the programs), things like the strange "future" built-in Python package, and so on.
>
> Bye,
> bearophile


I would think if a language designed in a migration path that worked it 
would allow things to be more fluid (on the library and language side). 
  This is one thing I believe has really hurt C++, since the 'good 
words' like null couldn't be used they had to settle for dumber names 
like nullptr_t.  From what I gather D's way 'out' is abuse of @

I would much rather the language be able to expand its turf at the 
expense of the existing codebases, as long as there was a way to 
_migrate the code cleanly_.

I envision something like this would work:

In addition to the 'module mypackage.mymodule' statement at the top of 
each file, should be a version number of D of some sort that the code 
was last built against.  A very high level language revision like D1 or D2.

Newer compilers would maintain the previous front-ends ability to parse 
these older files, purely for the sake of outputing TODO-like messages 
for how to upgrade the codebase to a newer version.

A simple example right now from D1 to D2 would be the way floating point 
literals are parsed is no longer compatible.  The UFCS changes could 
silently break existing code in theory and probably should be pointed 
out in some way before upgrading code from D1 to D2.