Re: [objc-improvements] Warnings when compiling GNUStep

[Alexander Malmberg]

Ziemowit Laski wrote:
> On Wednesday, Sep 3, 2003, at 17:35 US/Pacific, Alexander Malmberg
> wrote:
> > Ziemowit Laski wrote:
> >> On Wednesday, Sep 3, 2003, at 13:37 US/Pacific, Dirk Theisen wrote:
> >>> Covariant return types. Those are absolutely valid and I think you
> >>> know that. If not, I can dig up the relevant (oldish) papers. This
> >>> would give ObjC a little bit more expressive power in some cases and
> >>> another advantage over Java.
> >>
> >> Covariant return types (unlike covariant arguments :-) ) are valid in
> >> an OO-theoretic sense,
> >
> > Why not arguments? As far as I can tell, this applies to arguments as
> > well, but the "other way". Ie. for return types a subclass can specify
> > a
> > more specific type, while for arguments, a subclass can specify a more
> > generic type.
> 
> ...which would make them contravariant, not covariant. :-)

OK, I'll rephrase it: If we were to add handling of covariant return
types, is there any reason why we wouldn't want to add handling of
contravariant argument types?

[snip]
> >> You can declare that today, without prejudice (or warnings).
> >
> > But only because the compiler doesn't check prototypes properly. My
> > patch fixes that, and it would (definitely correctly) find both
> > prototypes, and (not necessarily correctly in this case) issue a
> > warning.
> 
> Personally, I like this idea, but it has been shot down within Apple.
> I suppose you can enable it only if !flag_next_runtime.

A warning option (-Wno-conflicting-prototypes?) for this would be ok
since it doesn't affect behavior (you wouldn't get the warning, but
you'd still get the same "random" prototype). If you really think it's
necessary, we could make that the default for -fnext-runtime; otherwise,
you (or others who don't want the warning) would simply use that option
when compiling.

[snip]
> 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")

If you want people to rely on rules for getting the "derived-most"
prototype, I suggest that we define these rules properly and document
them. It isn't clear that the current "rules", implicitly defined by the
implementation of the prototype search, is the best one.

In particular, it doesn't completely match what the runtime would do
wrt. categories. At runtime, categories override the main interface, but
in gcc, the main interface is searched before the categories and thus
overrides them.

[snip]
> >> (BTW, I have contacted "the proper authorities" on setting up an
> >> Apple-hosted ObjC mailing list; please stay tuned.)
> >
> > Would this be for generic objective-c discussion?
> 
> Yes.

Good! :)

I'm a bit worried that an apple-hosted list might be seen as too
*step-centered by non-*step objective-c users, but hopefully, a clear
"charter" should clear that up.

- Alexander Malmberg