On 3/13/14, Walter Bright <newshound2@digitalmars.com> wrote:
> I didn't even know about this client before the breakage.

I'm really getting tired of this argument. An unknown client (which you still haven't named, so as far as I'm concerned it might as well be just a reddit troll) comes out of the blue, complains about some small breakage which can *easily* be fixed in a point release, and suddenly that has to affect the decision on final by default. Also, the client hasn't bothered to file a bug report, and 2.056 has been released for a few weeks (nevermind the massively long beta cycle).

Why not do the obvious and just roll out the point release with the std.json fixes?

I only see this as getting worse, however. I mean the whole idea of client X deciding to ring up Andrei or Walter, NDAs to not disclose their name, and make an executive decision on some language/phobos feature.

Meanwhile, who's fixing the bugs and implementing features? People who are not on a payroll. So I think we the community and the developers have a right for a vote.

On Wednesday, March 12, 2014 15:50:06 Walter Bright wrote:
> So, there's the solution that has been proposed before:
> 
>     !final
>     !pure
>     !nothrow
>     etc.

It's arguably a bit ugly, but it's also arguably sorely needed - certainly the lack thereof has been complained about plenty of times before. So, completely aside from the issue of final by default, having a mechanism for negating all of these attributes would be quite valuable. And every other syntax that I can think of for this at the moment which wouldn't introduce another keyword would be overly verbose - though we were going to introduce keywords, something like not_final, not_pure, not_tothrow, etc. would be straightforward and probably wouldn't even break code (though you never know). The bang avoids that need though. The primary downside IMHO is how easily it could be missed when scanning over code, but we have that problem already when using bang in a condition, so that's nothing new.

- Jonathan M Davis

On Thursday, 13 March 2014 at 08:02:22 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Walter Bright <newshound2@digitalmars.com> wrote:
>> On 3/12/2014 4:01 PM, luka8088 wrote:
>>> How do you nearly lose a client over a change in a development branch
>>> which was never a part of any release? (or am I mistaken?)
>>
>> The change went into a release.
>
> Couldn't the client just file a bug? We've already agreed we'd make
> point releases for regression fixes. Client files bug, we fix it,
> upload the new compiler, everybody is happy. In the meantime the
> client could have continued to use the previous release.

Is there currently a snapshot installers for D? This may be a huge help in these cases. Aka nightly releases based off of commits.

On Thursday, 13 March 2014 at 06:02:27 UTC, Walter Bright wrote:
> On 3/12/2014 9:23 PM, Manu wrote:
>> It's not minor, and it's not achievable by other means though.
>
>     class C { final: ... }
>
> does it.
>
>
>> You and Andrei are the only resistance in this thread so far. Why don't you ask
>> 'temperamental client' what their opinion is? Give them a heads up, perhaps
>> they'll be more reasonable than you anticipate?
>
> I didn't even know about this client before the breakage. D has a lot of users who we don't know about.
>
>> Both myself and Don have stated on behalf of industrial clients that we embrace
>> breaking changes that move the language forward, or correct clearly identifiable
>> mistakes.
>
> Breaking changes has been a huge barrier to Don's company being able to move from D1 to D2. I still support D1 specifically for Don's company.

Yes, but the problem is not the changes which cause compile errors and force you to change your code in obvious ways. The problem is subtle changes to behaviour.

The worst breaking change in D2, by far, is the prevention of array stomping.

After that change, our code still runs, and produces exactly the same results, but it is so slow that it's completely unusable. This one of the main reasons we're still using D1.

On Thursday, 13 March 2014 at 08:16:50 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Walter Bright <newshound2@digitalmars.com> wrote:
>> I didn't even know about this client before the breakage.
>
> I'm really getting tired of this argument. An unknown client (which
> you still haven't named, so as far as I'm concerned it might as well
> be just a reddit troll) comes out of the blue, complains about some
> small breakage which can *easily* be fixed in a point release, and
> suddenly that has to affect the decision on final by default. Also,
> the client hasn't bothered to file a bug report, and 2.056 has been
> released for a few weeks (nevermind the massively long beta cycle).
>
> Why not do the obvious and just roll out the point release with the
> std.json fixes?
>
> I only see this as getting worse, however. I mean the whole idea of
> client X deciding to ring up Andrei or Walter, NDAs to not disclose
> their name, and make an executive decision on some language/phobos
> feature.
>
> Meanwhile, who's fixing the bugs and implementing features? People who
> are not on a payroll. So I think we the community and the developers
> have a right for a vote.

To be honest, whether or not the client really exists is irrelevant. We can't just keep making large breaking changes.

It's not just big companies that are effected either. Every breaking change potentially breaks some open source library. If that library is no longer maintained then it just stops working, and no one knows until a user comes along and tries to compile it. When it fails to compile, most users will just assume it doesn't work and move on. If that library was critical to their project then we probably lose a user.

As for the release time and beta: most people aren't on the forums daily. They don't know this is happening. The people on this forum are not representative D users.

I occasionally run Python scripts at work. I can assure you I have absolutely no idea when Python is going to get an update and I certainly have no idea when beta tests periods are being run!

On Thursday, 13 March 2014 at 04:58:05 UTC, Andrei Alexandrescu wrote:
> I hear you. Time to put this in a nice but firm manner: your arguments were understood but did not convince. The matter has been settled. There will be no final by default in the D programming language. Hope you understand.
>
>
> Thanks,
>
> Andrei

In light of this and as a nod to Manu's expertise and judgment on the matter:

We should make his reasoning on the importance of deliberately choosing virtual vs private in API-public classes prominent in documentation, wikis, books and other learning materials.

It may not be an important enough to justify a large language break, but if Manu says it is genuinely a problem in his industry, we should do our best to alleviate as much as is reasonable.

On Thursday, 13 March 2014 at 08:47:13 UTC, Peter Alexander wrote:
> To be honest, whether or not the client really exists is irrelevant. We can't just keep making large breaking changes.
>
> It's not just big companies that are effected either. Every breaking change potentially breaks some open source library. If that library is no longer maintained then it just stops working, and no one knows until a user comes along and tries to compile it. When it fails to compile, most users will just assume it doesn't work and move on. If that library was critical to their project then we probably lose a user.

It does effectively mean that we must stop development right here and now and never commit anything to dlang repos anymore. Because most breakage comes from bug-fixes for accepts-invalid. And it still renders unmaintained libraries unusable. Is that what you want?

> As for the release time and beta: most people aren't on the forums daily. They don't know this is happening. The people on this forum are not representative D users.
>
> I occasionally run Python scripts at work. I can assure you I have absolutely no idea when Python is going to get an update and I certainly have no idea when beta tests periods are being run!

Python scripts sometimes break for me when changing versions between 2.4 and 2.8 for example. Any changes to default python version are usually announced as major update.

On Thursday, 13 March 2014 at 08:16:50 UTC, Andrej Mitrovic wrote:
> On 3/13/14, Walter Bright <newshound2@digitalmars.com> wrote:
>> I didn't even know about this client before the breakage.
>
> I'm really getting tired of this argument. An unknown client (which
> you still haven't named, so as far as I'm concerned it might as well
> be just a reddit troll) comes out of the blue, complains about some
> small breakage which can *easily* be fixed in a point release, and
> suddenly that has to affect the decision on final by default. Also,
> the client hasn't bothered to file a bug report, and 2.056 has been
> released for a few weeks (nevermind the massively long beta cycle).
>

Hi guys,

I happen to be one of "the clients" in case.
We have several tools and apps written in D, in production, and we're actively trying to convert other portions of our systems too. We're an italian company managing the technical background of several startups (and "grown-ups") ranging from simple editorial/publishing business to realtime restaurant reservations and so on.

I think you can do every changes you need / you want but you should allow some time for people to update to new versions. No problems if you want to set a function as "deprecated" (or even a whole library) but please don't break compatibility all of a sudden (and without warning even in the changelog).

A breaking change drives to different problems:
- If you have code in production, code switching is a bit painful because you have to change code all at once. A short-period transition supported by "deprecated methods" makes it all easier to do.

- If your deployment system is automated (code updating and compiling) it's a bit difficult to sync the upgrade of compiler and code. If you upgrade your compiler first, code won't compile. If you upgrade your code first, it won't compile too. So in that (hopefully short) range of time your deployment system is not working.

- Changes could affect also third party libraries you're using in production, and that's even worse. You have to wait and hope they will fix that quickly.

- You can't always do a search/replace to fix the problems, and it could take a long time to fix all the involved code. A breaking change could also lead to a change of code structure. And probably it's a good idea to do all the needed tests after this, in order to check if the app is working as expected. In the meanwhile you can't use the new compiler with potential security/bug/performance fixes: you're stuck on the old version.

Thanks,
Daniele

Why you are speaking about breaking the code?
D was never been stable. It is full of bugs. Even a monkey can find a bug in DMD.
I think it's ok to make breaking changes if they are necessary.

Also it provides a tons of regressions with each release.
Well, do not speak about stable.