Re: New warnings (hopefully) in gcc 3.4

[Ziemowit Laski]

On Wednesday, Sep 3, 2003, at 05:09 US/Pacific, Nicola Pero wrote:
> Ok.  But from that point of view, even if you have a single prototype
> given, it might be all wrong, for all we know.

Yes, you're right -- having an 'id'-typed receiver and a single 
prototype floating around certainly doesn't
guarantee that that is the correct prototype to use. :-)

My motivation for falling back to a '(* id)(id, SEL, ...)' signature in 
case of conflicts was twofold:
 - That is the signature for the actual objc_msgSend() entry point; if 
you called it by hand,
   that's what you'd get.
 - I wanted a simple, _consistent_ and easy to understand failure mode. 
 Note that '(* id)(id, SEL, ...)'
   is picked if there are multiple prototypes, or if there is _no_ 
prototype -- in other words,
   whenver the compiler cannot decide what to use.

If we were to construct a Frankensteinian method signature out of 
competing signatures, then we would have to
acquire the ability for computing the least common ancestor (or lack 
thereof) for arbitrary types, _and_
explain the algorithm involved to users so that they know what to 
expect.  By the time we're done, the whole
thing might make C++ overload resolution look like a walk in the park. 
:-)

> If multiple declarations are found, the compiler can assume that the 
> right
> one is one of those (accepting the assumption above).  If the different
> declarations would cause it to generate the same code, then no matter
> which one is chosen, generated code will always be right - no matter 
> which
> of the different declarations which have been seen is actually 
> implemented
> by the id (it must be one of those, accepting the assumption above!), 
> the
> generated code is right.

But now you'd need to determine whether a group of signatures is 
codegen-compatible,
and you'll need to explain the resulting algorithm to users of the 
language.

> If it finds multiple conflicting declarations, say 2 really conflicting
> declarations, then - again assuming that the compiler has seen all the
> relevant method prototypes before the method call - the 'id' must
> implement the first one, or the second one: the compiler has a 50% of
> getting it right if it picks up one randomly.  If the compiler 
> fallbacks
> to a default fallback prototype in this case, it has a different
> probability of getting it right, which I feel would be less than 50%.  
> So
> maybe the compiler should actually pick up one randomly.  The only 
> other
> option I see is aborting compilation - falling back to an abstract 
> default
> does not seem particularly useful to me.

Perhaps I'm alone in my conviction, but I must say I really, really 
detest
the notion of a compiler doing things randomly. :-) :-)  Your 
probabilistic
argument sounds plausible (i.e., we might have slightly better odds of
picking a "codegen-correct" signature), but I honestly don't think that
programming language design should be concerned with odds. :-)

In the past, when the compiler picked a method out of a sea of competing
signatures, many users could have been led to believe that it had a
reason for doing so, i.e., there exists some overload resolution rule
in ObjC which caused that particular method to be picked.  So imagine
the users' frustration when, in the very next translation unit, the
compiler resolves the very same conflict in a different way! (This is
possible if, e.g., you #include headers in a different order.)  This is
no way for a programming language to behave. :-)

> Anyway, yes discussing this shows that Objective-C is somewhat lossy 
> and
> unformalized, and has a very practical spirit.  I guess it would be 
> nice
> to have things standardized.

Standards are nice (which is why everyone should have one :-)), but 
figuring
out corner cases such as this one is a good place to start, IMO.

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477