Jump to page: 1 220  
Page
Thread overview
Breaking backwards compatiblity
Mar 09, 2012
Walter Bright
Mar 09, 2012
Timon Gehr
Mar 09, 2012
Walter Bright
Mar 09, 2012
Jonathan M Davis
Mar 10, 2012
Walter Bright
Mar 11, 2012
David Nadlinger
Mar 11, 2012
deadalnix
Mar 09, 2012
H. S. Teoh
Mar 10, 2012
Andrej Mitrovic
Mar 10, 2012
Walter Bright
Mar 10, 2012
so
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
so
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
so
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
so
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
so
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Jérôme M. Berger
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
so
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Tove
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 11, 2012
H. S. Teoh
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
H. S. Teoh
Mar 11, 2012
Derek
Mar 11, 2012
Nick Sabalausky
Mar 12, 2012
Marco Leise
Mar 12, 2012
Nick Sabalausky
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
so
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
H. S. Teoh
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
so
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
Adam D. Ruppe
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
Marco Leise
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Sean Cavanaugh
Mar 10, 2012
H. S. Teoh
Mar 11, 2012
Walter Bright
Mar 11, 2012
H. S. Teoh
Mar 11, 2012
Nick Sabalausky
Mar 10, 2012
bearophile
Apr 03, 2012
Kagamin
Mar 09, 2012
Jonathan M Davis
Mar 11, 2012
deadalnix
Mar 09, 2012
Nick Sabalausky
Mar 09, 2012
Nick Sabalausky
Mar 09, 2012
Timon Gehr
Mar 10, 2012
Walter Bright
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
sclytrack
Mar 10, 2012
so
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Walter Bright
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Paulo Pinto
Mar 10, 2012
Walter Bright
Mar 11, 2012
deadalnix
Mar 11, 2012
Walter Bright
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Walter Bright
Mar 10, 2012
Paulo Pinto
Mar 11, 2012
deadalnix
Mar 10, 2012
Jeff Nowakowski
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Walter Bright
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Walter Bright
Mar 11, 2012
Walter Bright
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
Matej Nanut
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
Walter Bright
Mar 11, 2012
deadalnix
Mar 12, 2012
Walter Bright
Mar 13, 2012
Simen Kjærås
Mar 13, 2012
Nick Sabalausky
Mar 13, 2012
Simen Kjærås
Mar 13, 2012
James Miller
Mar 13, 2012
H. S. Teoh
Mar 13, 2012
Simen Kjærås
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
Nick Sabalausky
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
Nick Sabalausky
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
James Miller
Mar 11, 2012
Walter Bright
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
deadalnix
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
Nick Sabalausky
Mar 12, 2012
H. S. Teoh
Mar 12, 2012
Martin Nowak
Mar 11, 2012
H. S. Teoh
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
deadalnix
Mar 11, 2012
Walter Bright
Mar 11, 2012
Jonathan M Davis
Mar 11, 2012
bearophile
Mar 11, 2012
Walter Bright
Mar 11, 2012
deadalnix
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
deadalnix
Mar 12, 2012
H. S. Teoh
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
bearophile
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Sean Cavanaugh
Apr 01, 2012
Boris Wang
Mar 10, 2012
Jacob Carlborg
Mar 09, 2012
bearophile
Mar 10, 2012
Walter Bright
Mar 10, 2012
Walter Bright
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
Walter Bright
Mar 10, 2012
bearophile
Mar 10, 2012
Timon Gehr
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Mantis
Mar 10, 2012
Adam D. Ruppe
Mar 10, 2012
Walter Bright
Mar 10, 2012
David Nadlinger
Mar 10, 2012
Jonathan M Davis
Mar 10, 2012
Martin Nowak
Mar 10, 2012
ludi
Roadmap (was Re: Breaking backwards compatiblity)
Mar 10, 2012
Gour
Mar 10, 2012
Walter Bright
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Walter Bright
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 10, 2012
H. S. Teoh
Mar 10, 2012
Nick Sabalausky
Mar 11, 2012
deadalnix
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
Nick Sabalausky
Mar 11, 2012
deadalnix
Mar 11, 2012
Nick Sabalausky
March 09, 2012
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
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
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
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
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
"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
"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
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
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
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 6 7 8 9 10 11