On Wednesday, 3 June 2020 at 08:11:12 UTC, Panke wrote:
> 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


Yes, I think that's another option we can consider.

Let the user explicitly choose on the command-line, for each feature s/he want to use.


And quite interesting, this method (way of thinking) is exactly the key idea how Eiffel solved the multiple inheritance difficulty, while other language didn't: i.e. deal with each feature individually (in Eiffel), instead of all-or-nothing approach (in other languages).  (This is a bit off-topic on this thread, I will start a new thread about multiple inheritance in Eiffel).

On Wednesday, 3 June 2020 at 19:40:10 UTC, jmh530 wrote:
> 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);
> }


This is a bit off-topic in this thread, I started a new one:

https://forum.dlang.org/thread/obqthozmxwzhvrafothw@forum.dlang.org


will discuss the topic there.

On Thursday, 4 June 2020 at 06:47:16 UTC, mw wrote:
> Yes, I think that's another option we can consider.
>
> Let the user explicitly choose on the command-line, for each feature s/he want to use.
>
>
> And quite interesting, this method (way of thinking) is exactly the key idea how Eiffel solved the multiple inheritance difficulty, while other language didn't: i.e. deal with each feature individually (in Eiffel), instead of all-or-nothing approach (in other languages).  (This is a bit off-topic on this thread, I will start a new thread about multiple inheritance in Eiffel).

I think the crucial thing is that you can put your code in a state where it works both with '--incompatible_<name>=off' and '--incompatible_<name>=on. Thus you can migrate one feature, one part of your code base at a time. So it's not a all-or-nothing approach as it is when migrating to the next mayor compiler version that may contain multiple breaking changes at once.

On Tuesday, 2 June 2020 at 08:22:03 UTC, Seb wrote:
> On Tuesday, 2 June 2020 at 06:17:50 UTC, mw wrote:
>> [...]
>
>
> We're already doing the strong guarantee (dub test) continuously ;-)
> Check the buildkite.com/dlang or a buildkite link on any of the main D repos.
> At the moment it's about 50 projects, but that's already a huge pain to maintain as some of these projects are hard to build, relied on network to test, had spurious failures due to randomness in the testsuite, rely on very specific OS features (or versions) and every now and then a new version is released which either introduces some of the above or just has an outright problem with the testsuite.

The problem with this is that.
People submit fix-up pr's for the projects that fail with their change.