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

[Alexander Malmberg]

David Ayers wrote:
> Ziemowit Laski wrote:
> > On Saturday, Sep 6, 2003, at 00:54 US/Pacific, David Ayers wrote:
> >
> >> Given
> >> Class1: -(id)test1Float:(float)f int:(int)i;
> >> Class2: -(Object *)test1Float:(float)f int:(int)i;
> >>
> >> In the old case, you could get a warning about the compiler picking
> >> the wrong prototype but the results were correct.
> >
> >
> > In this particular case, the compiler picked a method signature out of
> > a hat that happened to work in that the intended codegen occurred.

In this case, it didn't just "happen to work". Note that it doesn't
matter which prototype the compiler picks, the program will do the right
thing anyway. However, if the compiler ignored both prototypes and used
the fallback, it wouldn't work since the float argument would be
promoted to a double.

This seems to be the primary technical advantage of picking a random
prototype. If all the prototypes are "mostly" compatible, it will do the
Right Thing without any advanced merging rules. IOW, it does well when
the conflicts are minor, but potentially fails completely (picks the
wrong one) when the conflict is big.

The fallback prototype approach's kindof-sortof tries to guess the
prototype from the arguments (by assuming that the prototype should have
the same types as the arguments). IOW, it can handle any conflict
decently, but always with a big risk of messing up completely (promoted
types, or the return type).

Anyway, at this point, I find it very unlikely that we're going to be
able to agree that some solution is substantially better than all
others. Thus, I don't think that it will be worth breaking compatibility
to get any new behavior. I'm going to restore the old behavior in my
patch (when searching for a prototype among all prototypes (ie. not for
a specific type), and there are several prototypes, a warning is issued
and a "random" prototype is used).

> > But just because the "results were correct" in this case does not make
> > the compiler correct. :-(  In fact, all you need to do here is add
> >
> >   Class3: -(void)test1Float:(float)f int:(int)i;
> >
> > to see just how "incorrect" things can get. :-)
>
> :-) 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 

I disagree. A warning and almost any behavior is better than a hard
error.

If you want an error when the compiler _might_ be doing the wrong thing,
use -Werror. Having the entire compile fail because the compiler isn't
sure that it's doing the right thing does not seem particularly useful
(especially in objective-c, where the compiler can _never_ be really
sure that it's doing the right thing).

- Alexander Malmberg