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. The user fix was also simple, just a tweak here and there to user code, and the compiler pointed out where each change needed to be made.

But we nearly lost a major client over it.

We're past the point where we can break everyone's code. It's going to cost us far, far more than we'll gain. (And you all know that if we could do massive do-overs, I'd get rid of put's auto-decode.)

Instead, one can write:

   class C { final: ... }

as a pattern, and everything in the class will be final. That leaves the "but what if I want a single virtual function?" There needs to be a way to locally turn off 'final'. Adding 'virtual' is one way to do that, but:

1. there are other attributes we might wish to turn off, like 'pure' and 'nothrow'.

2. it seems excessive to dedicate a keyword just for that.

So, there's the solution that has been proposed before:

   !final
   !pure
   !nothrow
   etc.

As long as it works like the opposite and can be labeled as they, I like it. It's a smart idea.

Would it mean that we would deprecate "nothrow" and replace it with "!throw"?

On 12.3.2014. 23:50, Walter Bright wrote:
> But we nearly lost a major client over it.

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?)

You seem to have a very demanding clients :)

On a side thought, maybe there should also be a stable branch?

On 12/03/14 23:50, Walter Bright wrote:
> 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. The user fix was also simple, just a tweak here and there to user code,
> and the compiler pointed out where each change needed to be made.
>
> But we nearly lost a major client over it.

I think for clarity it might be good to understand: was this near-loss because the client felt the language might have breaking changes in future, or because this breaking change had happened suddenly and with no warning?

A well-signposted and well-policed deprecation path is after all very different from what happened with std.json.

> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

These sound nice to have for themselves, whatever is decided about final-by-default.

On 03/12/2014 03:50 PM, Walter Bright wrote:

> So, there's the solution that has been proposed before:
>
>     !final
>     !pure
>     !nothrow
>     etc.

The same issue came up with 'version' recently. It is possible to start a version block like this:

    version(something):

However, it is not possible to get to the "else" part of that version block using the above syntax. Would the same syntax work for version as well?

    version(something):
        // ...

    !version(something):
        // ...

Note: Yes, it is possible to use curly braces for the same effect:

    version(something) {
        // ...

    } else {
        // ...
    }

The question is whether it makes sense to be consistent for version (and debug, etc.) as well.

Ali

On 13/03/14 00:14, Ali Çehreli wrote:
> However, it is not possible to get to the "else" part of that version block
> using the above syntax. Would the same syntax work for version as well?
>
>      version(something):
>          // ...
>
>      !version(something):
>          // ...

In that context, doesn't it make more sense:

    version(!something):
        // ...

On 03/12/2014 04:34 PM, Joseph Rushton Wakeling wrote:
> On 13/03/14 00:14, Ali Çehreli wrote:
>> However, it is not possible to get to the "else" part of that version
>> block
>> using the above syntax. Would the same syntax work for version as well?
>>
>>      version(something):
>>          // ...
>>
>>      !version(something):
>>          // ...
>
> In that context, doesn't it make more sense:
>
>      version(!something):
>          // ...
>

Agreed.

Ali

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.


> You seem to have a very demanding clients :)

Many clients have invested a great deal into D. They're entitled to be demanding.

On 3/12/2014 4:14 PM, Ali Çehreli wrote:
> The same issue came up with 'version' recently. It is possible to start a
> version block like this:
>
>      version(something):
>
> However, it is not possible to get to the "else" part of that version block
> using the above syntax. Would the same syntax work for version as well?
>
>      version(something):
>          // ...
>
>      !version(something):
>          // ...

Yes, this has come up before, in various forms. The short answer is unequivocably "no". I've expounded on this extensively in this n.g., but don't have a reference handy.