Re: [objc-improvements] Just remembered something about multiple method signatures...

[Nicola Pero]

> > :-) but this protoype is not just a conflicting prototype, it's an 
> > outright incompatible prototype, and as I believe Steve Naroff already 
> > suggested, it may be wiser to emit a hard error when prototypes are 
> > not just conflicting but really incompatible rather than second 
> > guessing any fallback prototype.
> 
> So now we need compiler logic to distinguish "conflicting" prototypes 
> from "incompatible" ones.  Are you offering to write it (and explain it 
> to end-users)? :-)

The compiler should be at least able to recognize that all objects (no
matter how casted) are compatible as arguments or return types.  For
example, id, NSObject *, id <NSObject>, NSString *, Class, they all
generate the same code.

Look at this example (a similar thing btw really happens in gnustep-gui):

- (BOOL) isBiggerThan: (NSObject *)anObject;
- (BOOL) isBiggerThan: (id<NSObject>)anObject;

If you have [myIdObject isBiggerThan: anotherId], then of course the
compiler should warn, but it would be silly for the compiler not to be
able to compile correctly the call.

Either the compiler should recognize that the prototypes generate the same
code, or the compiler should pick up at his discretion one of the two
prototypes; because they are compatible, the compiler will generate
correct code no matter which one it chooses.

Whatever the suggested mechanism for the compiler to solve the
ambiguities, I think the mechanism should do the right thing in those
simple, but common, cases where object arguments / return types are
objects slightly miscast (say, one is a NSMenuItem * and the other is a
id<NSMenuItem>, or one is NSObject * and the other one is id) in different
declarations.

This happens in practice, and while it's correct for the compiler to warn
that the prototypes are not consistent, it's so obvious what the correct
way of 'error-recovery' should be, that any mechanism which is not able to
do proper error-recovery in this case is not very good.