Walter Bright:

> The argument for final by default, as eloquently expressed by Manu, is a good one. Even Andrei agrees with it (!).
>
> The trouble, however, was illuminated most recently by the std.json regression that broke existing code. The breakage wasn't even intentional; it was a mistake.

Making final by default is a intentional and planned change, first you introduce "virtual" (it's already present in dmd 2.066alpha), then you give a warning, and then you deprecate things, and then later you generate errors. This gives time to people to fix the code. Even languages far older and far more widespread than D change, like the nullptr of C++ that replaces the 0 as null pointer. People that use D for production code should expect to give a look at the changelog every time a D version comes out and fix the code accordingly. I am keeping a large amount of D2 code updated and introducing the usage of "virtual" in my code will take an amount of time that is little compared to actually writing new code, refactoring code for other purposes, fixing bugs, etc. I don't think you can write D code today and expect it to work perfectly years from now. You have to keep your code updated or keep using the same compiler version.

We can introduce ways to better manage the change, like the "deprecate" keyword, introducing a refactoring tool like the one in Go language, and keep some backwards incompatible changes that the community and you regard as sufficiently important (like deprecating some usages of the comma operator, etc).

I don't even care much about "final by default".

Also in D there are several features that are "going to be deprecated". Like old style operator overloading, the built-in sort, and more and more. Keeping such things in the language for years without even a deprecation messages is bad. In the D.learn newsgroup I keep saying to people "don't use that, it's going to be deprecated". People use those things and if someday they will get actually deprecated they will cause a damage, perhaps comparable to introducing final by default. So please add deprecation messages now for all things that should be deprecated.

Bye,
bearophile

On Wednesday, 12 March 2014 at 23:51:41 UTC, bearophile wrote:
> Walter Bright:
>
>> The argument for final by default, as eloquently expressed by Manu, is a good one. Even Andrei agrees with it (!).
>>
>> The trouble, however, was illuminated most recently by the std.json regression that broke existing code. The breakage wasn't even intentional; it was a mistake.
>
> Making final by default is a intentional and planned change, first you introduce "virtual" (it's already present in dmd 2.066alpha), then you give a warning, and then you deprecate things, and then later you generate errors. This gives time to people to fix the code. Even languages far older and far more widespread than D change, like the nullptr of C++ that replaces the 0 as null pointer. People that use D for production code should expect to give a look at the changelog every time a D version comes out and fix the code accordingly. I am keeping a large amount of D2 code updated and introducing the usage of "virtual" in my code will take an amount of time that is little compared to actually writing new code, refactoring code for other purposes, fixing bugs, etc. I don't think you can write D code today and expect it to work perfectly years from now. You have to keep your code updated or keep using the same compiler version.
>
> We can introduce ways to better manage the change, like the "deprecate" keyword, introducing a refactoring tool like the one in Go language, and keep some backwards incompatible changes that the community and you regard as sufficiently important (like deprecating some usages of the comma operator, etc).
>
> I don't even care much about "final by default".
>
> Also in D there are several features that are "going to be deprecated". Like old style operator overloading, the built-in sort, and more and more. Keeping such things in the language for years without even a deprecation messages is bad. In the D.learn newsgroup I keep saying to people "don't use that, it's going to be deprecated". People use those things and if someday they will get actually deprecated they will cause a damage, perhaps comparable to introducing final by default. So please add deprecation messages now for all things that should be deprecated.
>
> Bye,
> bearophile

+1

On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
> But we nearly lost a major client over it.
>
> We're past the point where we can break everyone's code.

As someone who would like to be able to use D as a language, professionally, it's more important to me that D gain future clients than that it maintains the ones that it has. Even more important is that it does both of those things.

The JSON implementation, for example, is fine if you just want to read JSON data and if you are willing to look at the std.json.d file to figure out what the data structures look like, so you can actually interact with them. The whole thing should be replaced, because JSON is a fairly big part of modern life, and not having a very usable library for it is the sort of thing that would prevent someone from considering the language for a project.

To some extent, making changes that are non-breaking is good. But I don't think that's a full solution. Some of the features of the language just aren't where they need to be to encourage mass adoption, and fixing those will be breaking.

Sooner or later it's going to be necessary to either branch and support old versions of the compiler and the library, and/or to provide compatability flags. Flags like "--strict" are fairly common, so having a compiler mode that defaults to final declarations, defaults to nothrow, pure, safe, etc. seems pretty reasonable. You could even make that the default mode, with "--nonstrict" or something as a compiler flag preserving backwards compatability (eternally, or for a given period of time). Alternately, one could do like Java and have target versions for compiling. If you did that, you would probably want to lump breaking changes into a single release every few years, so that there isn't a different version number for every update.

I like the idea of having final: and !final:, but I think that compiler flags are the right answer for how to approach defaulting final.

On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:

> We're past the point where we can break everyone's code.

I suspect changes to the default behaviour of the language can be made if they are managed well.  It just needs to be done gradually.  Not making improvements to the language sacrifices future clients at the expense of existing clients.

Release x:
Add a -final_by_default switch.  Those that want 'final by default' can start building their code with that feature.  Default is still not 'not final by default'.  Warn with release that default behaviour will change in y+z releases.

Release x+y:
Add a -no_final_by_default flag and encourage users who don't want 'final by default' to use that flag in preparation for the next release.  Default is still 'not final by default'.  Repeat warning that default will change with next release.

Release x+y+z:
Make the switch to *final by default*.  Maintain the -no_final_by_default flag as long as you deem necessary.

In Addition:
Make binary and source code for previous versions *easily* accessible.  Procrastinators can always revert to a known state.

My 2 cents.

On 3/12/2014 5:02 PM, Chris Williams wrote:
> As someone who would like to be able to use D as a language, professionally,
> it's more important to me that D gain future clients than that it maintains the
> ones that it has. Even more important is that it does both of those things.

The D1 -> D2 transition very nearly destroyed D by sacrificing all the momentum it had.

On Thursday, 13 March 2014 at 00:15:50 UTC, Walter Bright wrote:
> On 3/12/2014 5:02 PM, Chris Williams wrote:
>> As someone who would like to be able to use D as a language, professionally,
>> it's more important to me that D gain future clients than that it maintains the
>> ones that it has. Even more important is that it does both of those things.
>
> The D1 -> D2 transition very nearly destroyed D by sacrificing all the momentum it had.

I didn't propose abandoning the current standard.

On 3/12/14, 5:02 PM, Chris Williams wrote:
> On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
>> But we nearly lost a major client over it.
>>
>> We're past the point where we can break everyone's code.
>
> As someone who would like to be able to use D as a language,
> professionally, it's more important to me that D gain future clients
> than that it maintains the ones that it has. Even more important is that
> it does both of those things.

The saying goes, "you can't make a bucket of yogurt without a spoonful of rennet". The pattern of resetting customer code into the next version must end. It's the one thing that both current and future users want: a pattern of stability and reliability.

> I like the idea of having final: and !final:, but I think that compiler
> flags are the right answer for how to approach defaulting final.

Sorry, no. We are opposed to having compiler flags define language semantics.


Andrei

On Thursday, 13 March 2014 at 00:18:06 UTC, Andrei Alexandrescu wrote:
> Sorry, no. We are opposed to having compiler flags define language semantics.

If done excessively, I could certainly see that. But outside of new languages that haven't gotten to that point yet, I don't know of any that don't have compiler/runtime flags of this sort. E.g. Java, Perl, C, C++, PHP, etc. I would be curious why you think D can escape this fate?

The only alternatives are:

1. Adding new syntax for things that are effectively the same (e.g. typedef vs phobos typedef) until the language definition is so long and full of so many variants that code by different people is mutually unintelligible, depending on when that person started learning the language, and the language starts to look like Perl with all the various symbols used to denote every other thing.

2. Deciding the language is perfect, regardless of whether it has ever reached a state that draws in clients.

On Thursday, 13 March 2014 at 00:18:06 UTC, Andrei Alexandrescu wrote:
> On 3/12/14, 5:02 PM, Chris Williams wrote:
>> As someone who would like to be able to use D as a language,
>> professionally, it's more important to me that D gain future clients
>> than that it maintains the ones that it has. Even more important is that
>> it does both of those things.
>
> The saying goes, "you can't make a bucket of yogurt without a spoonful of rennet". The pattern of resetting customer code into the next version must end. It's the one thing that both current and future users want: a pattern of stability and reliability.

Doesn't this sort of seal the language's fate in the long run, though? Eventually, new programming languages will appear which will learn from D's mistakes, and no new projects will be written in D.

Wasn't it here that I heard that a language which doesn't evolve is a dead language?

From looking at the atmosphere in this newsgroup, at least to me it appears obvious that there are, in fact, D users who would be glad to have their D code broken if it means that it will end up being written in a better programming language. (I'm one of them, for the record; I regularly break my own code anyway when refactoring my library.) Although I'm not advocating forking off a D3 here and now, the list of things we wish we could fix is only going to grow.

On 3/12/2014 5:18 PM, Andrei Alexandrescu wrote:
> We are opposed to having compiler flags define language semantics.

Yeah, that's one of those things that always seems like a reasonable idea, but experience with it isn't happy.