Introducing Nullable Reference Types in C#. Is there hope for D, too?

Jonathan M Davis newsgroup.d at jmdavisprog.com
Fri Nov 17 10:19:46 UTC 2017


On Friday, November 17, 2017 01:47:01 Michael V. Franklin via Digitalmars-d 
wrote:
> With Microsoft's proposed change, the compiler will emit a
> warning for Example C.  If you want to opt out of the warning,
> you'll need to declare `_instance` as `Test? _instance` (see the
> '?' there).

Personally, I'm flat out against anything that would generate a warning
rather than an error. If the compiler can't guarantee that your code is
wrong, then that check should be left up to a linter. As soon as something
is a warning in the compiler, you're going to be forced to fix it whether it
makes sense to fix it or not, because it's not appropriate to leave warnings
in a project. Having a way to tell the compiler to shut up improves things,
but it would be really annoying and is generally the sort of thing that
would be left to a linter.

If we can add something to the compiler which finds bugs 100% correctly and
generates an error for them, then I have no problem with that. But I don't
want to see any warnings about things that "might" be wrong. I think that it
was a huge mistake for Walter to add warnings to the compiler (which he only
did after a lot of nagging, and I suspect that he agrees that it was a
mistake; I'm sure that he's not entirely happy about it regardless). The
compiler should only ever complain about something that is guaranteed to be
wrong. Warnings are just errors in disguise but where what they're
complaining about isn't necessarily bad code.

> Notice that that is a "breaking" change for C#, but Microsoft
> still considers it an improvement to the language worth pursuing.
>   Is there hope for D, too?

In general, Walter doesn't like stuff that requires code flow analysis. I
believe that dmd does do _some_ code flow analysis, so I don't think that
that's a deal breaker, but it's the sort of thing that I think tends to get
shot down, because it gets complicated fast, and in general, D's solution to
this problem was to default initialize everything to values that were either
perfectly legitimate or as close as possible to error values so that the
problem would be caught quickly (and is simpler than code flow analysis). If
it can be implemented in a way that the compiler generates an error only
when it's completely sure that what you're doing is wrong, then I see no
problem with it, but it has to be an error, and the compiler can't be
generating errors when what you're doing could actually be fine.

Personally, I'm inclined to think that not initializing a variable which
defaults to null is a complete non-issue. Sure, it would be nice if the
compiler caught it and told you so that you didn't have to even run your
unit tests to find the problem (that's always nice), but it's also the sort
of thing that's immediately obvious as soon as you hit that piece of code
(which is very early on in the process if you're unit testing your code),
and it doesn't even require writing additional unit tests to catch it - any
tests that test the code properly will find the problem immediately. So, in
practice, it's a mistake that's quickly found and fixed. As such, while I
have no problem with the compiler giving an error when you've definitively
screwed up and are calling a member function on a null object, I question
that it actually fixes much, and I definitely don't want to be required to
do something to my code to make the compiler shut up, because it's
incorrectly decided that what I'm doing is wrong.

Another thing to consider with things like this though is generic code. It's
pretty trivial to have generic code run afoul of anything warning that what
you're doing might be wrong when it's actually just fine and pretty annoying
to write in a way that makes the compiler shut up about it (a warning for
unused variables would be a prime example where we'd have serious problems
like that). At the moment, I can't think of why that would be a problem in
this case (presuming that the compiler only complained when it definitively
knew that the code was calling a member function on a null reference or
pointer), but it's something that would have to be considered.

- Jonathan M Davis



More information about the Digitalmars-d mailing list