[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New warnings (hopefully) in gcc 3.4

From: Ziemowit Laski
Subject: Re: New warnings (hopefully) in gcc 3.4
Date: Wed, 3 Sep 2003 12:27:10 -0700

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]