I could not use referral than Eric Lippert :
-
Using null in a local context is most likely a bug , and in this context it is easy for the compiler to detect and report.
I disagree a little bit of this. A notification would be great, a warning is acceptable, but an error for me is something that the compiler should not issue, within the current C # philosophy. I even like it, I hate null , I'm just saying it's inconsistent. I consider it a team error to have decided that the compiler does this, but it's just my opinion. They decided that and we can only follow. Even Eric's response shows that they use heuristics that can produce the wrong results. This is not something a compiler should do for errors and even for alerts.
-
A field has a reasonable chance of being what it wanted, at least temporarily.
Or it was in the past, today has facilities and happened not to be so true, approached a bit of the probability of local use, but still has the possibility of null be the same. And the compiler would have difficulty analyzing this from the much wider context. They thought it was not worth the effort.
But note that language does not force anything anyway. You can not do it. Even in specification, it is impossible. There are always ways that make this check undecidable, and Eric's response shows this.
So the decision to put in the compiler was to the liking of the developers justifying it with the probability of getting allied with the ease of doing.
At the end of his response, he was given the options he had:
- Make a common, safe and often used language illegal
- Perform a very extensive review making the compilation take even hours to try to find a bug that may not even be there
- Adopt a default value and stay like this
They chose the last one.
My restriction is not to have done the same with the places.
But what I really wanted was that I did not have null . What they claim to have been the biggest mistake in language and that will partly resolve in C # 8 (maybe).
I could not find a better justification for making an error in using the uninitialized local variable. I fully understand their motive, it makes sense, but it gets kind of crooked. You have one more response from him that says something about it . There it confirms that all variables are initialized, even though null is not accepted as valid value in local context. Hans speaks of this too .
Note that the variable can be initialized later.
If they decide to eliminate this error one day does not change anything in the codes, compile everything existing today without changing any semantics. So it should not be a mistake. Error is for what never works, error is what is certainly error.
For the CLR method may require startup or not, remember that the CLR runs other languages, such as C ++ for example, that does not initialize. This is done by dialing CIL % with%. This does not restrict whether it is type by reference or not. This mark indicates that the stack frame of that method should be cleared, zeroed, so reference types will have .locals init value.
