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

[Chris Nicholson-Sauls]

sa wrote:
> == Quote from name (someanon at yahoo.com)'s article
>> http://d.puremagic.com/issues/show_bug.cgi?id=1419
>> Description:  [reply]  	 Opened: 2007-08-13 13:24
>> dupdefbug.d:
>> ================================
>> class A {
>>   int attr;
>> }
>> class B : A {
>>   int attr;
>> }
>> ================================
>> $ dmd.exe -c dupdefbug.d
>> no error reported.
>> It should report B.attr is dup of A.attr.
>> ------- Comment #1 From Walter Bright 2007-08-13 13:34 [reply] -------
>> Why should it be an error? Fields are not accessed virtually, so there is no
>> hijacking problem. The current behavior is as designed.
>> If you feel it should be changed, please start a thread in digitalmars.D and
>> present the case.
>> ==================================================================
>> I think 90% of the time this happens it is a bug, not by the programmer's
>> intention.
>> If it's designed to be so in D, I propose to change it; or at least reported
>> by the compiler.
> 
> This is particularly true in a large system where multiple people working on it,
> the programmer may simply forget what's defined in the super class; and when this
>  cause a program error (most of the time to the programmer's surpise), it may took
> several hours to find.
> 
> Since Walter want to discuss this issue on this NG, audience pleaes air your voice.

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.)

I'd favor making it a warning in the case of public/protected fields, and an error in the 
case of package/private fields.

-- Chris Nicholson-Sauls