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:

Command line flags work on a per-compiler-invocation basis, so that, depending on the set of files passed to the compiler, they affect code that they shouldn't, or don't affect the code that they should. This can be worked around to some degree by grouping files appropriately, but breaks for many language changes as soon as imports between these groups are involved.

Now, what I've always thought to be the obvious solution for this is to instead annotate the code on a per-module basis, using UDA syntax, pragmas, or something similar. In addition to avoiding import issues with external code, that would also allow to upgrade large code bases on a per-module basis.


    @semantic("dip1000") @semantic("default-to-safe")
    @disableSemantic("dip999")
    module foo;


    module foo;
    pragma(semantic, "dip1000");
    pragma(semantic, "default-to-safe");
    pragma(disableSemantic, "dip999");


The deprecation path would look like this:

1. new semantic is optionally available
2. new semantic enabled by default, mention in error messages that
   disabling is still possible
3. deprecate disabling the new semantic
4. make disabling an error
5. deprecate explicitly enabling the semantic
6. make enabling an error, or just keep it indefinitely


Finally, I think that this would considerably impact the rate of adoption during the preview phase, which I guess currently is extremely low due to the friction with external code and the need to upgrade full code bases at once.

I'm aware that this will require a different approach for the implementation and probably only makes sense for new DIPs, but it would also make some simple but long overdue changes, such as changing defaults to `@safe nothrow` (`final`?), a lot easier.

This was the most recent example of the issue:

https://github.com/vibe-d/vibe-core/issues/284

On 6/11/2021 12:36 AM, Sönke Ludwig wrote:
> Now, what I've always thought to be the obvious solution for this is to instead annotate the code on a per-module basis, using UDA syntax, pragmas, or something similar. In addition to avoiding import issues with external code, that would also allow to upgrade large code bases on a per-module basis.

Interestingly, this is how #ImportC is working.

On 11/6/21 6:31 pm, Luis wrote:
> GDC 10/11 isn't supporting D 2.081 ? https://wiki.dlang.org/GDC#Status
> 

In the recent GCC 11.1 announcement, Iain said the baseline is still 2.076.1:

  https://forum.dlang.org/post/yyblavikfluxsbtrdxry@forum.dlang.org

In the same post, Iain also said that GCC 12 should support the latest DMD front-end at the time of release, which -- as someone who primarily uses GDC -- would be nice.

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.