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