On 2009-09-27 07:38:59 -0400, Christopher Wright <dhase...@gmail.com> said:
I dislike these forced checks.
Let's say you're dealing with a compiler frontend. You have a semantic
node that just went through some semantic pass and is guaranteed, by
flow control and contracts, to have a certain property initialized that
was not initialized prior to that point.
The programmer knows the value isn't null. The compiler shouldn't force
checks. At most, it should have automated checks that disappear with
-release.
If the programmer knows a value isn't null, why not put the value in a
nullable-reference in the first place?
Also, it introduces more nesting.
Yes and no. It introduces an "if" statement for null checking, but only
for nullable references. If you know your reference can't be null it
should be non-nullable, and then you don't need to check.
Also, unless the compiler's flow analysis is great, it's a nuisance --
you can see that the error is bogus and have to insert extra checks.
First you're right, if the feature is implemented it should be well
implemented. Second, if in a few place you don't want an "if" clause,
you can always cast your nullable reference to a non-nullable one,
explicitly bypassing the safeties. If you write a cast, you are making
a consious decision of not checking for null, which is much better than
the current situation where it's very easy to forget to check for null.
It should be fine to provide a requireNotNull template and leave it at that.
It's fine to have such a template. But it's not nearly as useful.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
