Proposition for change in D regarding Inheriting overloaded methods

[Walter Bright]

Manfred Nowak wrote:
> Walter Bright wrote
>> closes all the known hijacking issues.
> 
> If accessing data declared private in another not imported module can 
> be called hijacking there is at least one more issue:
> 
> 
> Defining a Base class:
> 
> module def;
> class Base{int i;}
> 
> 
> and defining a Derived class with some operations and some private data 
> `hidden':
> 
> module def2;
> import std.stdio;
> import def;
> class Derived:Base{
>   private:
>   int hidden=41;  // foreign access possible
>   public:
>   void process( inout Base p){
>     scope d= new Derived;
>     d.hidden= 666;
>     d.i+=1;
>     p= d; // no upcast needed
>   }
>   void read( Base p){
>     scope d= cast(Derived)p;  //downcast needed
>     assert( d !is null);
>     writefln( "def2:", d.hidden);
>   }
> }
> 
> 
> and having a module that does some work:
> 
> module mod;
> private import std.stdio, def, def2;
> public:
> void process( inout Base p){
>   scope d= new Derived;
>   d.process= p; // stores Base, drops Derived
>   // do something with d?
> }
> void read( Base p){
>   scope d= new Derived;
>   d.read= p; // drops Derived
>   // do something with d?
> }
> 
> 
> 
> the following claim is currently (dmd.1.016,win32) true::
> 
> ! One can access the `private' data `hidden' defined in `module def2'
> ! by having access only to sources of `module def' and `module mod'.  
> 
> 
> This are about 25 LOC and if D is indeed designed to support auditing 
> well, it should be easy to spot that leak.

mod does not access hidden, neither does def. I don't understand the 
issue here.