dup field in sub-class should be reported by the compiler

[Bill Baxter]

Walter Bright wrote:
> Chris Nicholson-Sauls wrote:
>> Or, as has happened to me a time or two, the programmer may not even 
>> /know/ what's in the super class, if deriving from a class provided by 
>> a library for example.  (This is particularly true with private 
>> fields, of course.)
> 
> Exactly what problem does this solve? If you're writing a derived class, 
> and you create another field of the same name as a field in the base 
> class, what bug has been created? The base class functions will still 
> use the base class field, the derived class functions will still use the 
> derived class field. The fields aren't polymorphic, so no hijacking can 
> happen.
> 
> I just don't see the issue.
> 

I think there is another interaction that needs to be considered, and 
that is what happens when simple fields are converted to property 
methods.  Ideally one should be able to change a field to a property at 
will with little or no repercussions.  Currently when you make *both* 
base and derived fields into properties suddenly the behavior changes 
from non-virtual to virtual.  Maybe it's a separate issue but it seems 
like this could also be a source of difficult to find bugs.   And it 
also seems like making overriding fields an error would fix it.



--bb