Re: Compiler resolves to wrong overloaded constructor or method
From: Mike Schilling (mscottschilling_at_hotmail.com)
Date: 08/30/04
- Next message: NewGuy: "One more data grid question"
- Previous message: Barguast: "Strange stream problems"
- In reply to: Daniel O'Connell [C# MVP]: "Re: Compiler resolves to wrong overloaded constructor or method"
- Next in thread: Mike Schilling: "Re: Compiler resolves to wrong overloaded constructor or method"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 30 Aug 2004 10:25:09 -0700
"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eZdujwqjEHA.4092@TK2MSFTNGP10.phx.gbl...
>>>
>>> It is odd, but the compiler probably converts 0.0 to the literal 0. It
>>> may
>>> not be spec'd as such(I havn't checked teh fine print), but it is an
>>> understandable issue consider 0.0 and 0 are effectivly the same thing.
>>
>> They're not the same in any other context I know of, though: they're of
>> different types. For example:
>>
>> int i = 0.0;
>>
>> leads to the error
>>
>> error CS0029: Cannot implicitly convert type 'double' to 'int'
>>
>> Entirely correct, since such a cast can lose information, even though it
>> doesn't for this value.
>
> I agree, however I do suspect that 0 is defined the same or similarly. My
> guess would be that the Enum cast doesn't check type, instead it simply
> looks for a literal valued to 0. Whats more intresting, does something
> like 0.0f or 0l result in the enum overload being called?
Good question. What the C# spec says is:
13.1.3 Implicit enumeration conversions
An implicit enumeration conversion permits the decimal-integer-literal 0
to be converted to any enum-type.
According to 9.4.4.2, the decimal-integer-literal 0 can be
0, possibly suffixed by one of U u L l UL Ul uL ul LU Lu lU lu
0x0, possilby suffixed the same way
or of course 00, 0x00, 000, 0x000, etc, again possibly suffixed. And I
think this is exactly what was intended. It's not that any integer values
are implicitly converted to enums. It's that there is a special constant
that's a member of all enum types, it means "no flags set", and it's
spelled "0".
As far as I can see, that's the only place the implicit conversion should
apply, so, in theory, 0l yes, 0f no.
>> I think we agree here that the observed behavior seems to fall out of the
>> compiler implementation, rather than being derivable from the language
>> definition..
>
> Yes, I don't *think* there is anything in the spec that defines 0.0 as
> implicitly convertible to an enum, however I havn't sat down and traced
> the spec entirely, so I can't state that the spec doesn't define this.
I did some searching for "conversion", "cast:", etc. and didn't find
anything suggestive-looking.
>
> However, in the spec or not, it is now effectivly a semantically required
> portion of the language. Microsoft can't really change its compiler and
> third party compiler vendors would have to support this in either case,
> removing it will break code, unfortunatly.
There are ways to address this, e.g:
Version N+1 of the compiler issues a warning that the usage is
deprecated and will cause an error in future releases
Version N+2 issues an error unless a special compatibility-mode flag is
set
Version N+3 issues an error, period
But this is a small enough point that, I agree, there's no real point in
making the compiler stricter.
- Next message: NewGuy: "One more data grid question"
- Previous message: Barguast: "Strange stream problems"
- In reply to: Daniel O'Connell [C# MVP]: "Re: Compiler resolves to wrong overloaded constructor or method"
- Next in thread: Mike Schilling: "Re: Compiler resolves to wrong overloaded constructor or method"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
