[cfe-dev] [cfe-commits] r100942 - /cfe/trunk/lib/CodeGen/CGObjC.cpp

[David Chisnall]

On 11 Apr 2010, at 00:52, Chris Lattner wrote:

> I say no because it doesn't fit with the rest of the compiler, our current implementation of super is a ecological disaster and needs to be fixed, and it is obviously not been used enough to be reported yet.  I would argue that cast of super is much more widely used than parenthesized super. 

I suspect that it hasn't been reported because clang is only very recently able to compile most Objective-C code without random things breaking.  Now that most things are working we're getting into tidying up the last bits.  

>> Question two.  Should we do so with the existing infrastructure and the one-line change that I just made?  I say yes because:
>> 
>> - It is a trivial change.
>> - It works now.
>> - It allows existing code to be compiled with Clang that was previously requiring GCC.
>> 
>> You say no because is counter to your private sense of aesthetics.
> 
> This encourages broken code.  Continuing to reject it forces people to fix their broken code.  This is exactly what we did with cast of super, and the world is better place because of it.

Please can we define 'broken' here?  I gave a use case for it.  You have still, after three replies, not propose a way in which code that uses this idiom could be rewritten to work with clang.  Cast of super can, as I have already said be, worked around by declaring the private method in a category.  How do you work around macros that need to be able to take any valid receiver as an argument?  Give me a solution to this problem, and I'll shut up and write about your proposed work around in my new Objective-C book.  

Simply declaring code as broken when it has always worked in GCC and solves a specific problem is not a constructive approach.  The world is not a better place when you take code that works, is easy to read and understand, and declare unilaterally that it is broken and needs to be fixed, but don't propose a way of fixing it.

> Whether ObjCSuperExpr is removed or not seems completely unrelated to the user visible issue of whether the code is accepted or rejected.

But this is the argument that you seem to be using to motivate the user-visible change.

David