Deprecate implicit conversion between signed and unsigned integers

[Jonathan M Davis]

On Monday, May 13, 2024 8:04:34 AM MDT Nick Treleaven via dip.ideas wrote:
> On Monday, 13 May 2024 at 12:48:04 UTC, Dukc wrote:
> > Paul Backus kirjoitti 12.5.2024 klo 16.32:
> > Ditching all backwards-compatibility issues, it would be a good
> > idea. But, this would cause *tremendous* amounts of breakage.
> >
> > Before, I would have said it simply isn't worth it. But since
> > we're going to have editions, maybe. I'm still somewhat
> > sceptical though. Nothing will break without a warning and
> > people can stay at older editions if they want, but it's going
> > to add a lot of work for someone migrating 100_000 lines to a
> > new edition. That amount of code will likely have hundreds or
> > even thousands of deprecations to fix.
>
> I think even with editions we need to avoid making it hard to
> port code to a newer edition. So instead of a deprecation, we
> could make it a `-w` warning instead.

Deprecations are the language's tool for making changes where code will
later become illegal, and normally, the only result is that a message is
printed. No code is broken until the language is actually changed to remove
the deprecated feature.

In contrast, with how warnings are typically used in D, adding a warning is
as good as adding an error, since it's extremely common to compile with -w,
which makes all warnings errors, whereas arguably, -wi would be the better
choice (but -w has been around longer and is shorter).

Warnings are also an utterly terrible idea in general and really should
never have been added to the compiler. Even if you compile them in the
fashion that most compilers do and have them actually be warnings and not
errors, you inevitably end up in one of two situations with warnings:

1. You ignore many of them, because many of them are actually fine (since
they typically warn of something that's potentially a problem and not
something that's definitively a problem), and the ultimate result is that
you get a wall of warnings, burying any useful messages where they'll never
be seen, meaning that even the ones that should be fixed don't get fixed.

2. In order to avoid having a bunch of messages being printed and to avoid
burying warnings that really should be fixed, you "fix" all warnings. In
many cases, this requires changing code that is actually perfectly fine, but
whether the code was fine or not, the fact that you're always making sure to
remove any warnings that pop up makes it so that they might as well have
been errors instead of warnings.

The end result is that warnings are utterly useless. Either they should have
been errors, or they're better left to a linting tool. So, we really should
not be adding to that problem by introducing more warnings.

And the fact that D's type introspection often checks whether a particular
piece of code compiles in order to construct the checks for template
constraints and static ifs and the like means that having flags which change
whether a particular piece of code compiles or not is particularly bad for
D, and adding more warnings can actually change what code compiles or not
(or can even change which overload of a template is used). So, we really
shouldn't be adding more warnings.

Deprecations don't have any of those problems unless you choose to compile
with -de, which makes them warnings and which arguably shouldn't be a thing
for the same reasons that it's problematic that -w turns warnings into
errors. It actually affects conditional compilation and can do so in ways
that are not easy to detect.

- Jonathan M Davis