Transitions to new language semantics

Sönke Ludwig sludwig at outerproduct.org
Fri Jun 11 07:36:47 UTC 2021


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.


More information about the Digitalmars-d mailing list