Re: [objc-improvements] Warnings when compiling GNUStep

[Nicola Pero]

> >> For example, how should the compiler deal with invariant, unrelated or
> >> contra-variant return types?
> >
> > The same way that it deals with conflicting prototypes. To accept this,
> > we just need to change our rules for when prototypes conflict with each
> > other.
> 
> Currently, the compiler only cares about conflicting prototypes when
> dispatching to 'id'/'Class', and under no other circumstances.

I think the discussion could be made more general here, talking about
method declarations and implementations too, not just method invocations.

If you declare the same method twice in the same class (or maybe once in
the main class, once in a category, or maybe in two different categories
of the same class), but with different/conflicting signatures, you don't
get a warning ?  I think you do, but if you don't, that's something to fix
- you *must* get a warning.

A similar but different case, is if class A declares a method with a
signature, and class B (subclass of A) declares the same method with a
conflicting signature.

This can be very bad - it is a very basic idea of OO programming that it
must be possible to use an instance of class B (the subclass) wherever an
instance of the class A (the superclass) can be used.

If this basic principle is broken by the way in which methods are
declared, I think the compiler must warn openly and clearly.  I don't see
why you would want not to have these warnings.



> > The covariant checks would only apply when looking for prototypes for
> > the receiver's type. When the receiver is not known to implement the
> > method, we'd ignore any covariance and do a normal check of all known
> > prototypes.
> 
> But when you have a receiver type to work with (i.e., it is _not_ an 'id' or
> 'Class'), then you simply pick the closest ("derived-most") method signature
> and stop.  You never get multiply defined warnings when the receiver type
> is known.

Yes.  It's not when a method is called, but when the methods are
declared/implemented (inside an @interface/@implementation) that the
compiler should check that subclass methods are compatible with the
superclass methods.

But still, it seems somewhat obvious that the compiler *must* perform
those checks. :-)