Breaking backwards compatiblity

Jonathan M Davis jmdavisProg at gmx.com
Fri Mar 9 15:24:32 PST 2012


On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
> > On 09-03-2012 23:32, Walter Bright wrote:
> > >This statement is from Linus Torvalds about breaking binary
> > >compatibility:
> > >
> > >https://lkml.org/lkml/2012/3/8/495
> > >
> > >While I don't think we need to worry so much at the moment about
> > >breaking binary compatibility with new D releases, we do have a big
> > >problem with breaking source code compatibility.
> > >
> > >This is why we need to have a VERY high bar for breaking changes.
> > 
> > If we want to start being able to avoid breaking changes, we
> > *really* need to finally deprecate the stuff that's been slated for
> > deprecation for ages...
> 
> [...]
> 
> Does that include std.stdio and std.stream? When are we expecting std.io
> to be ready?
> 
> IMHO, this is one major change that needs to happen sooner rather than
> later. The current lack of interoperability between std.stdio and
> std.stream is a big detraction from Phobos' overall quality.

Note that he didn't say that we should _never_ make breaking changes but 
rather that we need to have a very high bar for making such changes. In 
particular, it's stuff like renaming functions without changing functionality 
that he's against.

If a module really needs a rewrite, then it'll get a rewrite, but we also need 
to do our best to avoid the need. And in the long run, it will hopefully be 
incredibly rare that we'll consider replacing modules. But there _are_ a few 
modules which are going to be replaced or rewritten. It's just that those are 
the modules that really need it and therefore meet the high bar required to 
make such changes.

- Jonathan M Davis


More information about the Digitalmars-d mailing list