Hacker News Reader

Comment by 46Bit | Hacker News Reader

"Dynamic languages make testing easier," paints a very broad brush. They have some very nice benefits, but also a lot of edgecases.

* An argument might be an int when you expected a float. This can be addressed by casting things with `float()` in every entrypoint, but it's more defensive to require a float and error out otherwise. Either way, problems only appear at runtime. * An object might be null and this only gets picked up at runtime - using Rust it's been very nice to have to explicitly say when things can be null.

I've found it can feel like luck when a complex Python program works correctly for real-world input, but it's also very powerful at getting something done. Tradeoffs.

View on HN

> An object might be null and this only gets picked up at runtime - using Rust it's been very nice to have to explicitly say when things can be null.

This point actually frustrates me greatly about C# 7. At some point, there was talk about non-nullable references being introduced into the language, which has been put on hold for at least another version. Personally, I think that feature should have been in the language since version 1. Every runtime error due to a null reference is one too many.

I have thought about creating a template struct with a single member that blows up if you try to insert null. Something like this:

  public struct NotNull<T>
  {
    private readonly T val;
    public T Value { 
      get { return val; } 
    }
    public NotNull(T v)
    {
        if (v==null) 
          throw new Exception(); 
        val = v;
    }
  }

However you can still create a class FOO with a member NotNull<T> xxx and xxx may be entirely uninitialized. It can be then passed from one method to another until you try to read it, so it basically does not give any guarantees.

I thinks this is why they pulled non-nullable types from C# - they couldn't figure out what to do in this case. If I were them I would force the constructor of FOO to blow up on exit if xxx is not populated. That would help a little bit. Although it still causes problems if a method is invoked from the constructor.

So yeah, it's a tough problem. Maybe they could add a check when a field of type NotNull<T> is read to throw an exception? That way you're still possibly in trouble when reading a field, but at least you can be confident that if you receive a method parameter NotNull<T> you know it's not null.

I also thought about solutions like this for a while, but frankly, every option sounds like the attempt to fix a leaking dam using duct tape.

Things like this have to be implemented properly. The problem is that this ties into the core architecture of the platform, not only the language - references are basically the most important implicit primitive there is in the CLR (implicit because not even the IL handles them like the other datatypes).

I'm not very informed on the subject, but I suspect that without a proper way to declare locals and members non-nullable in the CLR, the matter would get rather complicated - there'd be no possibility to communicate the requirement through method signatures, for example. And since you could call pretty much any C# method from other languages, I'd expect various problems there.

Of course, one option would be to only handle the initialization and assignment checks in the C# compiler (I guess that would be much easier) and simply generate conditional ArgumentNullExceptions in every method, but I suspect that this would be a problem for performance reasons.

Reply on news.ycombinator.com