Share via

Be a language designer redux...

  • Article

Thanks for all the responses to the question that I posed. The reason I posed it is that I've been seeing a lot of language requests coming through the MSDN feedback site, which is a good thing, but some of them are pretty obviously impractical, so I wanted to try to explore a little of the "language designer" mindset.

Several people pointed out that Cyrus had blogged about this a while back. That's true, though he doesn't explore things from a language designer standpoint, but rather from a language user standpoint. That's a nice place to start, but it doesn't really explore the areas you need to explore when thinking about adding a language feature.

So, here's my analysis of the request. Note that I'm only one member (so to be an ex-member) of the language design team, so there may be other opinions...

If you truly want to support non-null types, they need to be a runtime feature. That's the way that you get a secure, easy-to-use system that works the way users would want it to work.

Unfortunately, at this point in time, it would be somewhat difficult for the runtime team to do it. Even if they did, it's really not practical to modify all the existing libraries to take advantage of such a feature, as that would pretty much require that every bit of .NET code be revisited/recompiled. If you changed String.IndexOf() to only take a non-null string, think of how many places that's used in the .NET universe.

If we had it to do again, creating the runtime and CLR with such support seems like a good thing to do, but we weren't sharp enough to figure that out early on, so it's not something we can realistically add at this point.

So, where does that leave us? Well, it is possible to approach this from the "parameter validation" perspective rather than the "not null type" perspective, and you can likely get the effect that you want (ie not having to write your own parameter validation code), though it's decidedly less efficient to check for null everywhere than to just know that null is not a possible value. We will be talking about the parameter validation scenario in future design team meetings.

I think that Daniel O'Connell and Matthew W. Jackson probably came the closest to how I would approach the issue, so 250 points to each of them.

Comments

  • Anonymous
    August 17, 2004
    Yay! Points.

    Quick question though, what constrains the system from using a generic type(NotNull<T>) that can be implicitly converted to T. It doesn't operate entirely within the framework in that you would have to do (NotNull<T>) or (T!) casts when strings are returned, but I see no issue with passing the null value into a parameter.

    A further nicety would be return type overloading(and overload resolution) in C# andor VB or allowing the compiler to constrain valid methods to the set it wishes to use. Allowing return type overloading would allow the framework to slowly produce a duplicated interface which will be ignored by strictly CLS compliant consumers(since it is a generic) and would start to solve the issue. The C# compiler could simply hide those methods that are overloaded based on some metadata(with a compiler switch, of course). Its a touch contrived, but it may be a better, eventual solution. There is no issue with return nonnull values being assigned to nullable variables as nonnull is always correct. Parameters are the sticky point.

  • Anonymous
    August 17, 2004
    The comment has been removed

  • Anonymous
    August 17, 2004
    I think there's kind of a false dichotomy of perspectives here. For a statement S I can think of 6 ways to approach it:

    1) Hard runtime check- The runtime environment uses a verification prover or other computation to ensure S is true.

    2) Soft runtime check- The reference compiler emits a check to ensure S is true.

    3) Definite compiler check- The compiler asserts that S is true when needed but does not emit a check.

    4) Indefinite compiler check- The compiler asserts that S is definitely not false.

    5) Active documentation- An annotation is provided such that an intelligent editor can remind that S should be true and guide the user.

    6) Passive documentation- A canonical way of stating that S should be true.

    I know that language designers love options 1 and 2, but I think 3 and 6 have very good scenarios for this as well (and I'm sure the IDE people would be willing to champion 5). There seems to be some premature binning by starting out thinking about how to put this into the runtime.

  • Anonymous
    August 17, 2004
    Personally, I like 3 with metadata and existing runtime expectations(using a valuetype allows non-nullability without any runtime mods). Basically its a library solution that needs some language help, like Nullable Types. Though I suppose ! syntax would count as 6, would it not?

  • Anonymous
    August 17, 2004
    The comment has been removed

  • Anonymous
    August 17, 2004
    Code generation doesn't solve the problem as stated. It only solves a problem. The original isuse wasn't making null checks easier, but making passing null values illegal. Also, making it parameter only just seems to be a huge waste. Without local variables and definate non-null assignment, I dn't think the feature should be added.

    As for the array issue, thats a catch I hadn't thought of. That does make NonNullable<T> an incomplete solution. Time to put more thought into this, it seems, ;).

  • Anonymous
    August 17, 2004
    The comment has been removed

  • Anonymous
    August 17, 2004
    The comment has been removed

  • Anonymous
    August 17, 2004
    I need to proofread these:
    Correction: index >= this.Count

    I hope everyone got the idea though.

  • Anonymous
    August 17, 2004

    The deoration of parameters w/ attributes ([NotNull] etc.) that Matthew W. Jackson talked about, is a very good example of AOP applicability, where you use attributes to assign aspects to objects & methods.

    Having AOP would mean that an idea like that could be implemented and used now as opposed to having to wait for the language design team to see it, gain momentum, implement it and ship it in n+ years.

    I personally think this is a Very Good Thing.

    Other than that, I totally agree that pushing AOP in the hands of the average application coder is a Very Bad Thing.

    Giving it to the community though, so that tool vendors can bring aspect-oriented ideas like that one to life is something different.

  • Anonymous
    August 17, 2004
    isnt adding nullable types into the runtime and applying TDD to the BCL's enough to verify the newer functionality?

    and the existing code's verification is through the existing tests, correct?

  • Anonymous
    August 17, 2004
    The comment has been removed

  • Anonymous
    August 18, 2004
    The comment has been removed

  • Anonymous
    August 18, 2004
    I don't particularly mind seperate methods either, however declarative functionality would come in handy. The heavier question is interface based constraints, etc. How do you design an interface with restrictions, it'd have to be a set of metadata, it would be potentially unpleasent to say the least.

    One major piece of the throws design would be automatic unit tests to validate parameters. Your attributexml doc system would probably do the job as well. I would probably use xml docs myself.

  • Anonymous
    August 19, 2004
    The comment has been removed

  • Anonymous
    June 08, 2009
    PingBack from http://insomniacuresite.info/story.php?id=4240

  • Anonymous
    June 08, 2009
    PingBack from http://cellulitecreamsite.info/story.php?id=4292