Re: New warnings (hopefully) in gcc 3.4

[Alexander Malmberg]

David Ayers wrote:
> Nicola Pero wrote:
> >>[...] The @encode mechanism would still not recognize that
> >>-(id)method:(NSSize)aSize and -(id)method:(NSPoint)aPoint are
> >>equivalent.
> >>
> >Hmmm.  Are they really equivalent ?  The argument types seem to be quite
> >different.
> >
> Alex has just convinced me also.  :-)
> 
> My point was, "it used to work and now it wouldn't" (well the example
> was bad, I meant:
> -(NSSize)method and -(NSPoint)method )

This didn't work before, and won't work now (and yes, I tested :) ;
it'll pick one randomly, and it has a 50% chance of picking the wrong
one). The conflicts we're hoping to resolve are those that differ in the
object types, eg.:

-(NSSize) foo: (SomeClass *)object;
-(NSSize) foo: (SomeOtherClass *)object;

which, with my proposed merging scheme, would be merged to -(NSSize)
foo: (id)object, amidst a flurry of warnings. I don't think there's
anything sensible we can do if there's a conflict in a pure c type (eg.
different structures, or structures vs. objects). The fallback prototype
will get some of them right, eg.:

-(void) foo: (NSSize)s;
-(void) foo: (NSPoint)p;

would probably work ok since it'd get the type from the argument itself.
For others, the sender will just have to provide a cast.

> But yes, I could live w/o this.  I'm just thinking the IMP assumption
> must always be incorrect, even if it may work in many cases.

It isn't always incorrect. For methods that return 'id' or 'void' and
take arguments that match the promoted types of the argument expressions
in the sender, it will be correct. This includes methods that have
arguments that are objects, structures, ints, and doubles (however,
floats, chars, and shorts don't work, and the sender must get the types
of the arguments right).

(cc:ing because discuss-gnustep is taking forever to deliver mails.)

- Alexander Malmberg