[cfe-dev] Compatibility of Objective-C interface and id types

[Eli Friedman]

On Mon, Aug 25, 2008 at 3:15 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> Currently mergeTypes has the following code/comment:
> --
>   case Type::ObjCInterface:
>   {
>     // Distinct ObjC interfaces are not compatible; see
> canAssignObjCInterfaces
>     // for checking assignment/comparison safety
>     return QualType();
>   }
> --
>
> It isn't clear to me why we shouldn't be merging interface types which are
> in an
> inheritance relation to one another here. It seems like it was explicitly
> avoided,
> given the presence of canAssignObjCInterfaces but I don't see the reason
> yet.
>
> Wouldn't merging the interface allow simplifying and maybe removing
> canAssignObjCInterfaces?

The issue with the implementation before was that it wasn't
symmetrical, i.e. for some interfaces a and b, compatible(a,b) and
compatible(b,a) returned different results.  This is no good; it runs
completely counter to the spirit of C type compatibility and the rules
for every other type.

The first approach I tried was just making ObjC interfaces
symmetrically compatible, like your proposal; however, if I recall
correctly, this led to some testsuite failures because of missing
warnings about implicit down-casting on assignment.  If you think
that's better solved in a different way, go ahead and make whatever
changes you think are appropriate; I know very little about ObjC.

It's possible that it would be appropriate to have both symmetric and
asymmetric type merging modes; they would be identical for pure C
types, but could be different for ObjC interfaces.  I haven't thought
this through at all, though; I just came up with it a moment ago.

-Eli