On Tuesday, 2 June 2020 at 14:50:41 UTC, kinke wrote:
> On Tuesday, 2 June 2020 at 14:13:20 UTC, Mathias LANG wrote:
>> Instead of betas, which I think are more useful for manual testing before a release, I'd recommend to set up a dimension / a cron with nightly builds.
>> Github CI and the install script support them (hence so does travis-ci), by using `dmd-master` / `ldc-master` and `ldc-latest-ci` / `dmd-nightly`, respectively.
>
> Master is waaay too unstable IMHO. I definitely wouldn't use it for projects of mine, regardless how small.

Any decent CI has the ability to mark some failures as non-fatal.
So if master is unstable, well, it won't affect your project, but if you want to report it you can.

Also my mileage vary quite a bit. We've had LDC master enabled (and not allowing failure) for months now and everything's fine. Before we dropped DMD support, we also had DMD master, which sometimes had minor issues, but never was a huge burden to maintain either, since failures would be ignored.

On Wednesday, 3 June 2020 at 04:21:08 UTC, mw wrote:

> I think this release schedule is too frequent for a mature v2 language, it’s not application software, but language compiler!

+1

On Wednesday, 3 June 2020 at 04:21:08 UTC, mw wrote:
> On Wednesday, 3 June 2020 at 02:25:23 UTC, Walter Bright wrote:
>> On 6/1/2020 11:53 PM, mw wrote:
>>> If you seriously want to fix the multiple inheritance problem: freeze D2 prod, and make D3 dev, I also mean it seriously.
>>
>>
>> Yeah, well, even more breakage :-/
>
> The difference is: for a new *major* version release, breakage are more acceptable and tolerable by the users. Python 3  doesn’t have backward compatibility with Python 2, and there’s even a tool called ‘2to3’ coming with Python 3 to help people migrate. It’s a hard decision, but in the long run, it helps Python to be a more consistent language.
>
> With minor version release, it’s difficult to get things fixed, both for you and for the language users. Just as both parties have expressed in this very thread.
>
> In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3.
>
>
> Currently,
> https://dlang.org/changelog/release-schedule.html
>
> — New release are published every two months, on the first day of every uneven month.
> — Two weeks before a new release master is merged into stable and a first beta is released.
>
> I think this release schedule is too frequent for a mature v2 language, it’s not application software, but language compiler!
>
>
> No wonder kinke said:
>
>> Master is waaay too unstable IMHO. I definitely wouldn't use it for projects of mine, regardless how small.
>
>
> I hope you can think about this D2 / D3 suggestion.

Completely agree with your statements.

I am often about a year behind with compilers just so I can avoid being bit by breakage.

On 6/2/2020 9:21 PM, mw wrote:
> In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3.

We simply don't have the resources to support a fork of the language.

On 6/3/2020 12:52 AM, Atwork wrote:
> I am often about a year behind with compilers just so I can avoid being bit by breakage.

And there's nothing wrong with operating that way. If it's working for you, by all means.

On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
> On 6/2/2020 9:21 PM, mw wrote:
>> In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3.
>
> We simply don't have the resources to support a fork of the language.

Would be a schema as described here [1] be possible?

In a nutshell each breaking change is introduced with a switch named --incompatible_<name> that activates it. The default is to be turned off and this is quite similar to what we have with -preview=. After some time the default becomes on and you have to explicitly disable it, if you want to keep using your old code.

The crucial difference to what we do is: Every breaking change is guaranteed to have an migration path that allows you to change your code in a way that it works with both --incompatible_<name>=on and --incompatible_<name>=off. So you do not have to update your complete codebase on every breaking change and the recommendation is to never use --incompatible in your production setup.


[1] https://docs.bazel.build/versions/master/backward-compatibility.html

On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
> On 6/2/2020 9:21 PM, mw wrote:
>> In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3.
>
> We simply don't have the resources to support a fork of the language.

I wish people who asks for D3 were more ready to do the work or finance it. We're barely figuring out issues with D2.

On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
> [snip]

Thanks for that some interesting materials there about Eiffel.

As it says on the wikipedia page, the select & rename together drives their solution. Combining select and rename in one class is like an alias in D. However, D does not have the ability to prevent calling a member function of an inherited class. Using opDispatch doesn't work because it comes after calling member functions.

I think the most D-like way to incorporate this behavior is to allow @disable in a derived class for a base member function. Right now (see code below), you get a message about a depreciation (I think this one [1]) and not being able to @disable an overridden (you have to throw in an override) base class member function.

Probably would require a DIP, there is likely code out there that depends on always being able to call the base class member functions. Ideally, it would also handle base members, but this would likely require an even bigger change.

[1] https://dlang.org/deprecate.html#Overriding%20without%20override


import std.stdio: writeln;

class A
{
    int x;
    void foo(int x){
    	writeln("A");
    }
}

class B : A
{
    alias val = A.foo;

    //@disable this.x;
    @disable override void foo(int){}
}

void main() {
    A a = new A;
    B b = new B;
    b.val(1);
}

On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
> On 6/2/2020 9:21 PM, mw wrote:
>> In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3.
>
> We simply don't have the resources to support a fork of the language.

I won't call that a fork: I mean freeze D2 into maintenance mode: just bug fix, no new features.

https://github.com/dlang/dmd

shows: 198 contributors

let them help you with the D2 maintenance, so you can concentrate on D3.

On Wednesday, 3 June 2020 at 10:57:54 UTC, aberba wrote:
> On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
>> On 6/2/2020 9:21 PM, mw wrote:
>>> In my view, D2 has already been feature rich enough for people to do their work. What they want most is compiler stability, not any more new language features. By freezing D2, they will have a more stable platform to get their work done without worrying about breakage. And for you, it will buy you more time, e.g. a few years, to design carefully the next major features / fixes you want introduce in D3.
>>
>> We simply don't have the resources to support a fork of the language.
>
> I wish people who asks for D3 were more ready to do the work or finance it. We're barely figuring out issues with D2.

I just joined the dlang-community on github, thanks @Seb for the invitation.