switch and nullable type in C# 2.0

  • Thread starter Thread starter Octavio Hernandez
  • Start date Start date
Willy Denoyette said:
"MarkT [developmentor]" <[email protected]>
wrote in message
I just spent an hour looking at every place either nullable or switch
appears in the spec, and I could not find anything that explains the
behavior. However, the spec is pretty tough reading so I could easily
have
missed something. I tentatively vote "bug" on this one. You could submit
it
as a bug in the Microsoft Product Feedback Center to get some official
word
on it.
Click to expand...

Note that only the latest v2.0 beta version (2.0.50727) includes the
latest Design Change Request made for VS2005 and the CLR, one of these DCR
relate to nullable types, maybe one could try this using this build.
Note that it's allways safe to file an issue to Product Feedback though.
Click to expand...

No, it still works in that build. The change, as I undersatnd it, is that
nullable types are boxed into the underlying value instead of the
Nullable<T> value, ie.

int? x = null;
object y = x;

if (x == null)
...

With the change, x == null evaluates to true whereas before it would have
been false. http://blogs.msdn.com/somasegar/archive/2005/08/11/450640.aspx
covers the change.

The current spec certainly doesn't explain this behavior, so at worst it
would be an extended feature above and beyond the standard since the
behaviour is logical. Hopefuly they wil clear it up however.
 
Interesting that if you attempt to use integer value in "case" statement,
say 4, you get error message saying that there is no impllicit conversion
to convert 4 to SomeEnum type. So it looks that compiler recognizes just
SomeEnum as governing type for this switch.
 
Yuriy Solodkyy said:
Interesting that if you attempt to use integer value in "case" statement,
say 4, you get error message saying that there is no impllicit conversion
to convert 4 to SomeEnum type. So it looks that compiler recognizes just
SomeEnum as governing type for this switch.
Click to expand...

Ya, it appears that the governing type here is being derived directly from
the null type in a logical way, just without any kind of specification to
support it.
 
It seems to be an oversight in the spec. The behavior is as intended. Thanks
for pointing it out.
 
Yuriy Solodkyy said:
but with VS2005beta2 you can compile it and it works..
Click to expand...

Just as Oliver Sturm said, it works just as it should, so what's the
problem? I don't see any. Yes, may be documentation is not quite right in
this case, but what do you want? You want to change compiler so, that you'll
have to write explicit comversion every time? I don't think that would be
right decision.
 
Vitaliy said:
Just as Oliver Sturm said, it works just as it should, so what's the
problem? I don't see any. Yes, may be documentation is not quite right in
this case, but what do you want? You want to change compiler so, that
you'll
have to write explicit comversion every time? I don't think that would be
right decision.
Click to expand...

Just a short comment, as you're talking about what I said: of course the
implementation makes sense the way it works - I don't think anybody was
contradicting that in this thread. But apparently, as I wasn't immediately
prepared to believe but studious documentation readers made clear, what
the language does is not compliant with the documentation; this should of
course be fixed, hopefully on the side of the documentation. It's
important to find and fix this kind of issue to assure compatibility with
other implementations of the C# language.


Oliver Sturm
 
I just tried to understand how compiler handles it, as it seemed to me that
it should produce error accroding to specification.
 
Vitaliy Kourokhtin said:
Just as Oliver Sturm said, it works just as it should, so what's the
problem? I don't see any. Yes, may be documentation is not quite right in
this case, but what do you want? You want to change compiler so, that you'll
have to write explicit comversion every time? I don't think that would be
right decision.
Click to expand...

I think "what you want" is for the documentation to match the
implementation. Now, that allows for the case where you correct the
documentation to match the implementation, as here.

What's the point of a specification if it's not accurate?
 
Back
Top