Function Hijacking article

[Reiner Pope]

Stewart Gordon wrote:
> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
> news:ff8qto$1k6r$2 at digitalmars.com...
>> Stewart Gordon wrote:
>>> "Walter Bright" <newshound1 at digitalmars.com> wrote in message 
>>> news:ff8fi1$fs7$1 at digitalmars.com...
>>>> Stewart Gordon wrote:
>>> <snip>
>>>>> And I noticed that the requirement to specify the override 
>>>>> attribute is neither implemented nor documented under 
>>>>> attribute.html - what gives?
>>>>
>>>> It is documented in the function.html and attribute.html.
>>>
>>> I still can't find it anywhere.
>>
>> In attribute.html, click on "override" under "Attribute" in the 
>> grammar section.
> 
> I already did.  I get this:
> 
> "The override attribute applies to virtual functions. It means that the 
> function must override a function with the same name and parameters in a 
> base class. The override attribute is useful for catching errors when a 
> base class's member function gets its parameters changed, and all 
> derived classes need to have their overriding functions updated."
> 
> followed by a code example that demonstrates this.  So it states that 
> the override attribute _may_ be used if it overrides, and _must not_ be 
> used if it doesn't override.  I can't see anything there that relates to 
> a circumstance in which the override attribute _must_ be used to make 
> the code compile.  What am I missing?
> 
>> In function.html, search for "override".
> 
> I already did.  The only hits either don't address the question of 
> required or not, or blatantly violate the requirement.
> 
> <snip>
>>> I'm not with you.  How exactly does this render my example 
>>> susceptible to the hijacking problem?
>>
>> If Qwert defines a function def:
>>
>> void def()
>> {
>> yuiop(1);
>> }
> 
> You state that this particular form of hijacking problem occurs because 
> a call originally to yuiop(long) becomes a call to yuiop(int) when such 
> a method is added to the base class.  But since yuiop(1) can never have 
> possibly been a call to any yuiop(string), why is it a problem?

I suppose this could cause problems:

struct S
{
     string opImplicitCastTo() {...}
     int opImplicitCastTo() {...}
}
...
yuiop( S() )


     -- Reiner