Please do not reply to this email- if you want to comment on the bug, go to the URL shown below and enter your comments there.
Changed by [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=78367 --- shadow/78367 2006-05-11 06:47:34.000000000 -0400 +++ shadow/78367.tmp.17014 2006-05-12 06:00:06.000000000 -0400 @@ -1,22 +1,21 @@ Bug#: 78367 Product: Mono: Compilers Version: 1.1 -OS: +OS: unknown OS Details: Status: NEW Resolution: -Severity: +Severity: Unknown Priority: Normal Component: C# AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] TargetMilestone: --- URL: -Cc: Summary: incorrect CS0019 : hidden member takes precedence over "new" member on resolving member In the following code, there are "new Bar Document" in the derived class XElement, and "Foo Document" in the base class Element. In CrashHere(), Document.Root should be regarded as IHoge as defined in @@ -71,6 +70,58 @@ Additional Information: The same problem happens when you create another derived class YElement and move CrashHere() method there. I extracted this small repro code from SharpVectorGraphics 0.4 Alpha. + +------- Additional Comments From [EMAIL PROTECTED] 2006-05-12 06:00 ------- +I remember that you had filed a similar bug before. + +You're comparing a reference of class 'XElement' with a reference of +interface 'IHoge', where XElement does _not_ implement IHoge. The +argument to allow it is that some unknown derived class of XElement +could implement IHoge. + +Basically, my reading of the standard was that it doesn't allow this. +The code to handle this can get ugly, too. Also, the workaround is +simple: cast one of the references to type 'object'. + +From section 14.9.6: I'm cut/pasting from +http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_7_9.asp +(read 13.3.1 for 6.3.1 below) + +----------------- +The predefined reference type equality operators require the operands +to be reference-type values or the value null; furthermore, they +require that a standard implicit conversion (Section 6.3.1) exists +from the type of either operand to the type of the other operand. +Unless both of these conditions are true, a compile-time error occurs. +----------------- + +followed by some informative (not normative) text: + +----------------- +Notable implications of these rules are: + + * It is a compile-time error to use the predefined reference type +equality operators to compare two references that are known to be +different at compile-time. For example, if the compile-time types of +the operands are two class types A and B, and if neither A nor B +derives from the other, then it would be impossible for the two +operands to reference the same object. Thus, the operation is +considered a compile-time error. +----------------- + +Now, one can build a shaky case for CSC's behaviour by only reading +the informative part and ignoring the normative part. + +So, the question is this: + + * is this a widely used idiom (seems to be not so rare, since Eno +filed this bug twice ;-) + + * is there a chance that Microsoft will fix their compiler to +disallow this code? + + * should we care? The standard's on our side + _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
