Cheers for the counter-example.

I can't think of a compare method in the Objective-C core lib (the biggest nil-swallowing lib I know of). Does anyone know of one? Would be interesting to see how it's handled and if it causes issues.

You could return an enum, which would allow you to use non-obvious values (Lower = 1, Equal = 2, Higher = 3), though this would make it a bit of a pain to interface with C-style libs.

Obviously the presence of a work-around doesn't mean nil-swallowing is a good idea, but rather cements the idea that library authors need to put in extra effort to make sure nil receivers are handled appropriately.

> I can't think of a compare method in the Objective-C core lib (the biggest nil-swallowing lib I know of). Does anyone know of one? Would be interesting to see how it's handled and if it causes issues.

Maybe I misunderstood you, but there is plenty of compare:'s in Cocoa: http://cl.ly/image/1a112f1B1W1g.

They all return an enum that's either -1, 0 or 1.

judofyr's code is actually valid. Most "value" classes have compare: — NSString, NSDate, NSNumber, etc.

I'd argue this is correct. If a is nil, it's not comparable. The alternative would be to throw an exception, which is pretty simple to emulate by checking.

Also, nils aren't allowed in the collection classes, so sorting with compare: will simply never encounter this case.

True, although none of the other return values make that much sense with nil either.