Could new keyword help function hijacking and prevented aliasing all over the place??

[Steven Schveighoffer]

On Fri, 27 May 2011 10:54:14 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> It is completely against the spirit of the language to decide that a  
> call is resolved to an invalid method during runtime. There is no other  
> feature remotely related to hiddenfunc.
>
> A couple of years ago, Walter gave a talk on hijacking to NWCPP. It all  
> went well until HiddenFunc, at which point Walter's assertion that the  
> way out was by throwing an exception was hotly debated. Several people  
> suggested alternative, of whom one proposed (4) above. Everybody agreed  
> it's a good solution, and Walter had the presence of mind and humility  
> to acknowledge that solution and to promise to look into implementing  
> it. Unfortunately, that event was forgotten... until now.

I just tried it out.  If one implements an overload that is not  
contentious (for example, between int and string), no hidden func error is  
thrown.  So indeed the compiler has a notion of when a function would be  
hijacked.

I thought HiddenFuncError was thrown whenever you called any overloaded  
base method.  So I agree with you, this needs to be fixed.  Is there a  
bugzilla on it, or should we file one?  Let's not lose it again.

-Steve