Stream of consciousness answer; I don't have time to make it self-consistent.
On 11 Dec 2011, at 10:58 AM, Matt Neuburg wrote: > Now, I think I know why [NSString string] is declared as returning an id - > it's because it's a class cluster, right? It occurs to me that if ClassA defines +classAWithFoo:, and SubclassB overrides it without redeclaring it (as it need not), and some NotSubclassC declares it independently, publishing any return type other than id is in fact not as productive as you seem to hope. +[NSString string] is not a special case for class clusters. If you could be certain that only NSString and its subclasses would implement that class method, then a return type of NSString* would be the right contract for the API to offer. It does in fact return _an_ NSString object — it is guaranteed to fulfill the contract for NSString — it just hides how that object's actual class implements it. It's a principle of object-oriented programming that an instance of any class is-an instance of its superclasses. With the return type defined as id, the declaration NSAtrributedString * attrString = [NSAttributedString string]; is not merely useful, but legal without a downcast. You could get some comfort from clang 3's "related result type" inference of the type of alloc/init expressions, but I don't see how the feature could be extended to convenience constructors — unless they are defined to return "instancetype". See <http://clang.llvm.org/docs/LanguageExtensions.html#objc_instancetype> — F _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
