[Mono-bugs] [Bug 78367][Nor] Changed - incorrect CS0019 : hidden member takes precedence over "new" member on resolving member

[bugzilla-daemon at bugzilla.ximian.com]

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 rharinath at novell.com.

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: rharinath at novell.com                            
 ReportedBy: atsushi at ximian.com               
 QAContact: mono-bugs at ximian.com
 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 rharinath at novell.com  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
+