March 09, 2012 Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
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. |
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 03/09/2012 11:32 PM, 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.
Most bug fixes are breaking changes. I don't think we are there yet.
|
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 3/9/2012 2:41 PM, Timon Gehr wrote:
> On 03/09/2012 11:32 PM, 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.
>
> Most bug fixes are breaking changes. I don't think we are there yet.
There have been some gratuitous ones, in my not-so-humble opinion. Those need to stop.
|
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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... -- - Alex |
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Friday, March 09, 2012 14:44:05 Walter Bright wrote:
> On 3/9/2012 2:41 PM, Timon Gehr wrote:
> > On 03/09/2012 11:32 PM, 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.
> >
> > Most bug fixes are breaking changes. I don't think we are there yet.
>
> There have been some gratuitous ones, in my not-so-humble opinion. Those need to stop.
Do you have any specific ones in mind? There were a number of them to try and make it so that names were more consistent with regards to camelcasing and the like, but those changes have largely stopped (or at least are well into the deprecation process if they haven't been completed yet).
The only stuff along those lines that I'm aware of at the moment is the discussion on making some changes to some of the function names in core.time and std.datetime, because some people don't like some of them. And no such changes have been made yet (though there are people are still looking to make some of them).
- Jonathan M Davis
|
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | "Walter Bright" <newshound2@digitalmars.com> wrote in message news:jje0er$24mb$1@digitalmars.com... > 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. Freezing things against breaking changes is all fine and good, but NOT before they're reached a point where they're good enough to be frozen. Premature freezing is how you create cruft and other such shit. Let's not go jumping any guns here. |
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | "Nick Sabalausky" <a@a.a> wrote in message news:jje2cg$27tg$1@digitalmars.com... > "Walter Bright" <newshound2@digitalmars.com> wrote in message news:jje0er$24mb$1@digitalmars.com... >> 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. > > Freezing things against breaking changes is all fine and good, but NOT before they're reached a point where they're good enough to be frozen. Premature freezing is how you create cruft and other such shit. Let's not go jumping any guns here. > Keep in mind, too, that Linux has decades of legacy and millions of users. That's a *very* different situation from Phobos. Apples and oranges. |
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alex Rønne Petersen | 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. T -- Жил-был король когда-то, при нём блоха жила. |
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 10-03-2012 00:14, 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. > > > T > Well, I was mostly thinking language-wise. But yeah, those too. -- - Alex |
March 09, 2012 Re: Breaking backwards compatiblity | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter: > 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. D will naturally progressively slow down the rhythm of its new breaking changes, but even very old languages introduce some breaking changes (see some of the changes in C++11), and D is not yet mature enough to slow them sharply down now. In D there are some unfinished parts still. Finishing them will probably break something. Bug fixing are now breaking things in every release, and I don't want to see an arbitrary stop to those improvements now. If you stop breaking changes, we'll not be able to fix a nasty situation like ("Some untidy attributes"): http://d.puremagic.com/issues/show_bug.cgi?id=3934 In bug 3934 there is a lot of stuff that I'd love to break in the code of the silly programmers that have used it. Another small breaking change, that I have argued about for years: http://d.puremagic.com/issues/show_bug.cgi?id=7444 Or this one "Default arguments of out and ref arguments": http://d.puremagic.com/issues/show_bug.cgi?id=5850 If today people write code with default arguments at ref/out arguments, forbidding those default arguments will break their code. "A bug-prone situation with AAs": http://d.puremagic.com/issues/show_bug.cgi?id=3825 Currently string literals concatenation is accepted like this: auto s = "foo" "bar"; But you have accepted to disallow this statically (and require a ~), after a request of mine. If today people write such code, this will be a breaking change for their code. Do you want me to list some more bugs now that are small breaking changes? I am willing to discuss each one of them. Stopping all those improvements right now at once is exceptionally unwise. Bye, bearophile |
Copyright © 1999-2021 by the D Language Foundation