Re: problems with forward invocation (gcc bug?)

[Wim Oudshoorn]

You wrote:
> Richard Frith-Macdonald wrote:
> > > This might not possible.  We know that -cString returns a (char *)
> > > but the offending line said:
> > >
> > > [x cString];
> > >
> > > And if the compiler only knows that x is of generic (id) type.
> > > How can it know what the return type of cString is supposed to be?
> >
> > Good point ... I guess we can't call it a compiler bug then ... more
> > of a language bug.  Now if we had a type encoding for a return type
> > of 'dont care' the compiler could generate some info.
>
> No, this is not a language/compiler bug. The [x cString] code with x
> being id will compile correctly with gcc. There are only two situations:
>
> a) there is only a single definition of cString - in this case the
> return type is obvious and taken by the compiler

But still, with x being `id', the selector is untyped, regardless
if the compiler generates the correct calling sequence.

>
> b) there is either no definition or multiple definitions of the selector
> - in this case the compiler throws a warning (maybe it should throw an
> error) and chooses some (usually unusable), default behaviour. If there
> is no def it assumes 'id' for all selector parts.

I do not have gcc here, but I think that

@selector (selectorThatIsNeverDefined);

does not result in a warning by gcc.
Beside that, I think that untyped selectors are quite
usefull, especially in the DO case, or in combination
with NSSelectorFromString ().

Wim Oudshoorn.