On Friday, May 01, 2015 10:40:46 Daniel Kozak via Digitalmars-d wrote:
> I do not want to change any of the issue above, I just do not understand why some breaking changes are OK, and some other are not so ok.

Well, fixing bugs often results in breaking changes. Sometimes, it's determined that something causes enough bugs that we make it illegal (e.g. implicit fallthrough in switch statements), and that would be a breaking change (though in principle, it finds and prevents enough bugs to be worth it). Sometimes, we're forced to make changes in the language to enable something we want or need to do or to make an existing feature work correctly, and that can result in breaking changes. Sometimes, we decide that a previous design decision was enough of a mistake to be worth changing even though it breaks code. There are a number of reasons for it.

Ultimately, the question is whether the changes are worth the problems that the breakage causes (which often depends on how much code is likely to break and how critical it is that the change be made; e.g. fixing a bug is pretty much always going to be worth the breakage, whereas making a design change often wouldn't be). And whether the change is made tends to depend on who's involved in the decision. Some devs are more willing to make breaking changes than others, and it's not always clear whether something is really a bug or just an unfortunate result of other design decisions. Walter tends to reject most breaking changes, but he might consider something to be a bug that needs to be fixed whereas someone else thinks that it's legitimate behavior. And Walter doesn't review every pull request, so sometimes, breaking changes are made without his knowledge or consent.

We make _far_ fewer breaking changes than we used to, and the bar has been raised considerably, but we do upon occasion make breaking changes when we think that it's worth it, and that's always going to be on a case-by-case basis. So, it's very hard to give a definitive answer as to what is and isn't an acceptable breaking change. It really depends on the change in question.

In general, I think that most breaking changes occur due to regressions that aren't caught, in which case, they're bugs, not purposeful changes. And while we're doing better at catching and preventing regressions, we definitely don't get them all. We really need more folks trying out the betas with their projects and reporting any issues that they find in order to get anywhere near catching them all (and we'll probably never catch 100% of them, particularly if a regression affects only rare cases). So, frequently, code breakage is completely accidental.

- Jonathan M Davis

On Friday, May 01, 2015 08:51:10 Paolo Invernizzi via Digitalmars-d wrote:
> On Friday, 1 May 2015 at 08:40:25 UTC, Daniel Kozak wrote:
> >
> > <snip>
> >
> > I just do not understand why
> > some breaking changes are OK, and some other are not so ok.
> >
>
> +1.... but, again, I'm hopeless that W+A will understand the break-my-code spirit...

Walter tends to err on the side of wanting to break no code whatsoever, and he almost never seems to understand when folks actually _want_ their code broken, because they consider the current situation to be worse than having their code temporarily broken (e.g. because leaving the current state of things in place would result in far more bugs in the future). In light of that, I'm actually kind of surprised that he's agreed to some of the code breakage that we've done (e.g. making implicit falthrough in switch statements illegal).

But to be fair, it's often hard to know when it's worth making a breaking change even if you're willing to make them in order to catch and prevent bugs or to clean-up a language featuer or whatever. And pretty much every time you make such a change, some folks will be very happy about, whereas others will be very _un_happy about it. So, to some extent, you just can't win. And when that's the case, it's frequently easier to just leave things as they are and avoid making breaking changes even if it might be better if they were made.

- Jonathan M Davis

On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:
> Walter tends to err on the side of wanting to break no code whatsoever, and
> he almost never seems to understand when folks actually _want_ their code
> broken, because they consider the current situation to be worse than having
> their code temporarily broken (e.g. because leaving the current state of
> things in place would result in far more bugs in the future).

It's not really as simple as that, and I think I understand W & A's position here.

It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of "I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D."

I was in the "break my code" camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions.

I would love a cleaner D language, if only it could be enforced just onto NEW code.

On 5/1/2015 2:28 AM, Vladimir Panteleev wrote:
> I was in the "break my code" camp for a long time, but this has gradually
> changed as the amount of D code I've written grew. Let me tell you, it's totally
> not fun when you need to quickly fix a D program you wrote 3 years ago because
> something is on fire and it needs fixing now, and discover you have to make a
> bunch of changes just to get it to compile again. The alternative is using an
> older compiler, and DVM helps with that - but this doesn't work if the fix is in
> a library which is not compatible with older compiler versions.

I've had the mispleasure several times of reaching back to update some older D code of mine, that works fine, and finding not only will it not compile, I have to re-architect parts of it.

The situation was so bad I wound up creating:

    https://github.com/DigitalMars/undeaD

and if *I* find this annoying, irritating, disheartening, etc., I can only imagine how others feel about it.

Sometimes the older code is complex, underdocumented, and I don't remember how it worked or how it needs to be re-architected. But it does work, it just doesn't compile anymore.

Imagine you find some cool D library, download it, and find it doesn't compile. How many of you are going to fix it? Or are you just going to chuck it to /dev/null?

How many users have we lost because of this?

This really blows. And things like that isnan => isNaN really has GOT TO STOP. Just today I found it broke some older piece of code I had that's perfectly correct.

We need to be working on things that MATTER. What happens with every Reddit post about D? No matter the topic, it always becomes about D not being usable without the GC.

A big piece of the fix for that is going through Phobos and fixing code that returns gc allocated arrays with algorithms that return ranges.

Why am I the only one working on that? I don't remember anyone having a problem with isnan.

I'm willing to break existing code for a large benefit. Not a small one. And certainly not when the benefit is zero, like the isnan renaming. And I'm willing to break code that relied on bugs in the compiler.

On 1 May 2015 at 11:28, Vladimir Panteleev via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:
>>
>> Walter tends to err on the side of wanting to break no code whatsoever,
>> and
>> he almost never seems to understand when folks actually _want_ their code
>> broken, because they consider the current situation to be worse than
>> having
>> their code temporarily broken (e.g. because leaving the current state of
>> things in place would result in far more bugs in the future).
>
>
> It's not really as simple as that, and I think I understand W & A's position here.
>
> It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of "I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D."
>
> I was in the "break my code" camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions.
>
> I would love a cleaner D language, if only it could be enforced just onto NEW code.

pragma(old_code);

On Friday, 1 May 2015 at 09:28:58 UTC, Vladimir Panteleev wrote:
> On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:
>> Walter tends to err on the side of wanting to break no code whatsoever, and
>> he almost never seems to understand when folks actually _want_ their code
>> broken, because they consider the current situation to be worse than having
>> their code temporarily broken (e.g. because leaving the current state of
>> things in place would result in far more bugs in the future).
>
> It's not really as simple as that, and I think I understand W & A's position here.
>
> It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of "I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D."
>
> I was in the "break my code" camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions.
>
> I would love a cleaner D language, if only it could be enforced just onto NEW code.

Most of commercial code _is_ maintained, fix it for a change like this one is _trivial_.

This apply to _every programming language_ : we are doing it right now, today, to upgrade a commercial library that we sell to a different visual studio edition.

Hunting for bugs is wasted time.
Explaining the pitfalls of the language is wasted time.
Explaining the inconsistency of the language is wasted time.
Reling on convenctions instead of being forced by a tool is wasted time.

This comes from my experience, as the CTO of a company with a big D codebase: reddit turned out to be some sort of pestilence for D, IMHO...

/P

On 1 May 2015 at 12:03, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 1 May 2015 at 11:28, Vladimir Panteleev via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Friday, 1 May 2015 at 09:08:11 UTC, Jonathan M Davis wrote:
>>>
>>> Walter tends to err on the side of wanting to break no code whatsoever,
>>> and
>>> he almost never seems to understand when folks actually _want_ their code
>>> broken, because they consider the current situation to be worse than
>>> having
>>> their code temporarily broken (e.g. because leaving the current state of
>>> things in place would result in far more bugs in the future).
>>
>>
>> It's not really as simple as that, and I think I understand W & A's position here.
>>
>> It seems that every once in a while, someone on Reddit etc. is going to say something along the lines of "I once tried to compile some code written in D, and it didn't compile with none of the three compilers. I'm not familiar with the language or code, so fixing it was out of the question, and so was randomly trying old compiler versions. If other people are going to have the same experience using MY code, then I don't see the point in investing time in D."
>>
>> I was in the "break my code" camp for a long time, but this has gradually changed as the amount of D code I've written grew. Let me tell you, it's totally not fun when you need to quickly fix a D program you wrote 3 years ago because something is on fire and it needs fixing now, and discover you have to make a bunch of changes just to get it to compile again. The alternative is using an older compiler, and DVM helps with that - but this doesn't work if the fix is in a library which is not compatible with older compiler versions.
>>
>> I would love a cleaner D language, if only it could be enforced just onto NEW code.
>
> pragma(old_code);


Actually, one could even take inspiration from Perl's 'use VERSION' as a way tell the compiler to use the semantics/warnings of a previous release.  But then it comes down to a feeling of some competing element between cleaner D language vs. cleaner D implementation.

Iain.

On Fri, 01 May 2015 02:55:00 -0700, Walter Bright wrote:

> Imagine you find some cool D library, download it, and find it doesn't
> compile.
> How many of you are going to fix it? Or are you just going to chuck it
> to /dev/null?
> 
> How many users have we lost because of this?

zero. if that library is SO old, it is unmaintained anyway, so there will be no not only new features, but no bugfixes too. anyone wanting to use such library in new code is insane.

> This really blows. And things like that isnan => isNaN really has GOT TO STOP.

sed -r 's/\bisnan\b/isNaN/'

> We need to be working on things that MATTER.

language consistency IS matter. i wouldn't even try to explain newcomer what `if (arr)` really means, why it means that, and why in the name of hell he should care about `arr.ptr`, while in all other places it doesn't matter. and i can tell you how many users you lost due to THIS: at least ten. ten real users vs ??? imaginary users.

> What happens with every
> Reddit post about D? No matter the topic, it always becomes about D not
> being usable without the GC.

why should anyone care about what is going on on reddit? ah, i know. it's 'cause Random Reddit Poster, who never wrote something bigger than "hello, world" in D is first-class citizen, and people who using D every day to write all kind of programs are second-class citizens.

> Why am I the only one working on that?

maybe 'cause other people who can devote their time to this doesn't see random reddit mumbling as a serious motivation?

> I'm willing to break existing code for a large benefit. Not a small one.

having consistent language is a large benefit. but it's not immediate one.

On Friday, 1 May 2015 at 07:06:53 UTC, Andrei Alexandrescu wrote:
> On 4/30/15 6:12 PM, Daniel Murphy wrote:
>> "Andrei Alexandrescu"  wrote in message
>> news:mhto1k$2dk0$1@digitalmars.com...
>>
>>> Nothing negates that. It's a judgment call. Please let's stop here.
>>> Thanks. -- Andrei
>>
>> Please stop trying to undo this improvement.  Just fix your code and
>> move on.
>> Thanks.
>
> After we have discussed this matter extensively Walter and I decided to move forward and undo this language change.
>
> It's a judgment call. The advantages and disadvantages of this have been discussed extensively. We are accountable for decisions like this, and we must make the decisions we believe are right. That said, making a decision when there are strong feelings and opinions on both sides is always difficult.
>
> We would really like to find consensus, but failing that, request your indulgence.
>
> Please review: https://github.com/D-Programming-Language/dmd/pull/4623
>
>
> Thanks,
>
> Andrei

You say you want to find a consensus, but neither you nor walter provide a good sum up of your discussion.

That makes it hard to express any good rebuttal or even be understanding of you position.

People here have presented situations where they faced bugs due to the current behavior, and even Walter got it wrong in the doc in the past (which makes any point saying that the current behavior is desirable moot).

Right now, the main reason expressed on your side is the breakage in std.allocator, which is known to be fairly different than your usual D code. It lets most people here with the feeling that breaking our code is no big deal (I have breakage in SDC with pretty much every release, usually for the better, sometime completely for nothing like when struct construction were not lvalues anymore) but breaking yours is.

It has been presented in this thread how the current behavior lead to confusion (including, as already mentioned, from Walter himself) and how unit tests is likely to NOT catch it, because it create this kind of situation where things mostly works, but really do not.

The only person here that has presented convincing evidence against the change is Vladimir, and that's be really interesting to dig into his report to know if all the reported uses are correct or if the change discovered some bug in his code.

Possible less painful transition path also have been proposed, but none has been discussed.

I sure have made the mistake myself several time and have to make people fix their PR because of incorrect use of slice to bool conversion on a regular basis, so I'd expect that this damn thing to be a positive change. It seems that the majority of people agree. Granted, it is not because most people think something that it makes it right, but that certainly is a good justification to at least provide detailed explanation of why the majority is wrong if it is the case.

On Friday, 1 May 2015 at 09:54:43 UTC, Walter Bright wrote:
> I've had the mispleasure several times of reaching back to update some older D code of mine, that works fine, and finding not only will it not compile, I have to re-architect parts of it.
>
> The situation was so bad I wound up creating:
>
>     https://github.com/DigitalMars/undeaD
>
> and if *I* find this annoying, irritating, disheartening, etc., I can only imagine how others feel about it.
>

Why is that a valid argument AGAINST the change, while the exact same argument was not valid the other way around. You were confused writing the doc in the first place, and if *You* find it confusing, you should be able to imagine how others feel about it.

I'm sorry, but it is just backward rationalization.

> Imagine you find some cool D library, download it, and find it doesn't compile. How many of you are going to fix it? Or are you just going to chuck it to /dev/null?
>
> How many users have we lost because of this?
>
> This really blows. And things like that isnan => isNaN really has GOT TO STOP. Just today I found it broke some older piece of code I had that's perfectly correct.
>

This breaks code without fixing anything. So, because of some stupid change have been made in the past, that mean that all change should be avoided ? That is once again bogus logic.

> We need to be working on things that MATTER. What happens with every Reddit post about D? No matter the topic, it always becomes about D not being usable without the GC.
>

This change expose bugs. It does matter. isnan vs isNaN does not. It does not matter. This is not about isNan or about the GC, so there is no point in bringing these subjects into the conversation unless the goal is to make everything confusing and OT.

> A big piece of the fix for that is going through Phobos and fixing code that returns gc allocated arrays with algorithms that return ranges.
>

True, but OT.

> Why am I the only one working on that? I don't remember anyone having a problem with isnan.
>

Red herring. This is not about isnan, never was, never will be. You are the one trying to bring that up.