On Friday, 11 June 2021 at 11:27:03 UTC, Ola Fosheim Grøstad wrote:
> I would find it much more reassuring if a comprehensive solution was developed as a completely separate compiler branch.
> future branch that is considered unstable until all the corner cases have been ironed out.
> This also allows more heavy restructuring of compiler internals, like introducing an appropriate IR (which is needed for things like borrowing or ARC, if you want something solid).

This would be short-sighted. It'd mean that the experimental feature developers would then have to backport all the compiler improvements that have been done while the feature was experimental. Its easier to account for the experimental features when doing the restructuring.

Second, if using an experimental feature requires compiling a separate compiler branch, not as many will use it. Hence, less real world testing, and even less issues ironed out.

> The cost of moving to a more complete solution after something incomplete has been made official could break the camel's back.
>
> The piece-by-piece approach is a slippery slope.

We already have a three-round DIP process to catch issues before we make the new feature official. We probably need to be more explicit about what is still experimental and what is official, though. I think it wouldn't hurt to document that status to each of the preview switches in DMD.

On Friday, 11 June 2021 at 11:27:03 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 11 June 2021 at 07:36:47 UTC, Sönke Ludwig wrote:
>> This is something that should have been discussed already, but I can't remember whether that was actually the case, and it always bothers me every time there is friction with new DIP switches.
>>
>> Right now, new language semantics are introduced using `-preview` and `-revert` switches, which unfortunately has a massive drawback:
>
> I am troubled in general by the implementation of incomplete solutions and making them gradually available.
>
> I would find it much more reassuring if a comprehensive solution was developed as a completely separate compiler branch. Basically have a stable branch (as is), and then a future branch that is considered unstable until all the corner cases have been ironed out. This also allows more heavy restructuring of compiler internals, like introducing an appropriate IR (which is needed for things like borrowing or ARC, if you want something solid).
>
> The cost of moving to a more complete solution after something incomplete has been made official could break the camel's back.
>
> The piece-by-piece approach is a slippery slope.

I think this is a good point.

Having an unstable compiler would allow removing things that don't work so well again, while having the advantage of having a big user base trying it out (and complaining about bugs) - though this could also be seen as inconvenience for users and authors e.g. when libraries are only working with an unstable branch or change in behavior with the unstable compiler.

On Friday, 11 June 2021 at 11:27:03 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 11 June 2021 at 07:36:47 UTC, Sönke Ludwig wrote:
>> [...]
>
> I am troubled in general by the implementation of incomplete solutions and making them gradually available.
>
> I would find it much more reassuring if a comprehensive solution was developed as a completely separate compiler branch. Basically have a stable branch (as is), and then a future branch that is considered unstable until all the corner cases have been ironed out. This also allows more heavy restructuring of compiler internals, like introducing an appropriate IR (which is needed for things like borrowing or ARC, if you want something solid).
>
> The cost of moving to a more complete solution after something incomplete has been made official could break the camel's back.
>
> The piece-by-piece approach is a slippery slope.

Doesn't Rust do something like this? A problem I read concerning its ecosystem is the tendency to target nightly, and thus using a more stable branch of the compiler leaves one high and dry, so to speak.

On Friday, 11 June 2021 at 11:48:22 UTC, Dukc wrote:
> This would be short-sighted. It'd mean that the experimental feature developers would then have to backport all the compiler improvements that have been done while the feature was experimental. Its easier to account for the experimental features when doing the restructuring.

I would go the opposite direction. Improvements in the unstable branch that has proven itself stable and with low semantic impact (like bugfixes and security fixes) would be backported as a revision of the stable branch.

> Second, if using an experimental feature requires compiling a separate compiler branch, not as many will use it. Hence, less real world testing, and even less issues ironed out.

It should be compiled and packaged as a nightly delivery. (Automated)

On Friday, 11 June 2021 at 11:57:03 UTC, surlymoor wrote:
> Doesn't Rust do something like this? A problem I read concerning its ecosystem is the tendency to target nightly, and thus using a more stable branch of the compiler leaves one high and dry, so to speak.

I don't know. But I think some languages (Ada?) have different feature-profiles. D does also have a profile called "BetterC".

So, one could define a "maximal compatible" feature profile for D and use a linter to verify that a library stays within that profile.

Say, if you wanted to write a geometry library, then you might want to target BetterC as the minimum profile, but use conditional version statements to enable more features for other profiles.

D as a language have the mechanisms, I think, but it isn't used effectively as it requires someone to work out a "standard way" of writing libraries.