View mode: basic / threaded / horizontal-split · Log in · Help
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
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
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
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
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
"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
"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
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
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
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home