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