<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jan 18, 2016, at 12:41 PM, Philippe Hausler &lt;<a href="mailto:phausler@apple.com" class="">phausler@apple.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">One note to those constants; there are a number of them (NSError domains in particular) that are intended to be a complement to the application space defines; such that your app could define a “MyGreatAppErrorDomain” and a “MyGreatFrameworkErrorDomain” in addition to the NSCocoaErrorDomain. So this isn’t exactly an enum but more so a non closed set of values. Enums are usually closed sets so that they can be switched upon exhaustively. Others would definitely improve the state of affairs for both objc and swift in that technically you could get a warning/error in objc if the type was not correct and there would be the swift ramifications you mentioned as well.</div></div></div></blockquote><div><br class=""></div><div>Great point, and for that reason I switched away from NSError domains in my proposal. It’s a much more clear win to use this for something like HealthKit constants where values outside of the constants may not be used. For NSError domains, leaving the type as NSString is probably best to indicate that custom strings are supported.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">On the other hand it might be useful for the (desperately in need of some updating) NSLocale method</div><div class=""><br class=""></div><div class="">@interface&nbsp;NSLocale : NSObject &lt;NSCopying, NSSecureCoding&gt;<br class="">...<br class="">- (nullable&nbsp;id)objectForKey:(NSLocaleKey)key; // we could limit the keys accepted here to just the appropriate values in the “enum"</div><div class="">...</div><div class="">@end</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">From a brief survey of the APIs this would be useful for they mostly seem to be “dictionary based programming” cases which expose poorly in swift because they don’t have type safe return values. Adding more swift-friendly interfaces to those APIs is not off the table; because it is not just the keys that are the issue here but the return values too (see NSLocale’s example). Not to say we couldn’t do both, but would it be the case that if the un-typed return values that access by keys are replaced with better, more safe interfaces, this still be needed?</div></div></blockquote><div class=""><br class="webkit-block-placeholder"></div><div class="">The “dictionary based programming” examples could definitely use a bit of an API refresh, as you’ve noticed with the return types. This proposal’s real aim is APIs that use strings to mean one of a finite set of values. Take HealthKit:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">+ (nullable HKQuantityType *)quantityTypeForIdentifier:(NSString *)identifier;</blockquote></div><div class=""><br class=""></div><div class="">The return value here is typesafe, but the identifier is a string. HKTypeIdentifiers.h defines these identifiers. Here’s one set:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">HK_EXTERN&nbsp;NSString&nbsp;*&nbsp;const HKQuantityTypeIdentifierBodyMassIndex;<div class="">HK_EXTERN NSString&nbsp;*&nbsp;const HKQuantityTypeIdentifierBodyFatPercentage;</div><div class="">HK_EXTERN NSString&nbsp;*&nbsp;const HKQuantityTypeIdentifierHeight;</div><div class="">HK_EXTERN NSString&nbsp;*&nbsp;const &nbsp;HKQuantityTypeIdentifierBodyMass;</div><div class="">HK_EXTERN NSString&nbsp;*&nbsp;const&nbsp;HKQuantityTypeIdentifierLeanBodyMass;</div></div></blockquote><div class=""><br class=""></div><div class="">Since the user isn’t permitted to use their own identifiers here, this is an ideal case for replacement. It also gives the user a better hint as to where to find these constants. Rewriting the Objective-C method along these lines:</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class="">+&nbsp;(nullable HKQuantityType *)quantityTypeForIdentifier:(HKQuantityTypeIdentifier)identifier;</blockquote><div class=""><br class=""></div></div></div><div class="">Would give the user a hint in the name of the type for where to look in the documentation for these identifiers.</div><div class=""><br class=""></div><div class="">I think frameworks like HealthKit with constant string identifiers would benefit greatly from this change, as would other frameworks like CoreText with opaque keys and values used to construct dictionaries.</div><div class=""><br class=""></div><div class=""><br class="webkit-block-placeholder"></div><div class=""><div style="font-family: Helvetica; line-height: normal; orphans: 2; text-align: -webkit-auto; widows: 2; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="line-height: normal; text-align: -webkit-auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="line-height: normal; text-align: -webkit-auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Jeff Kelley</div><div class=""><br class=""></div><div class=""><a href="mailto:SlaunchaMan@gmail.com" class="">SlaunchaMan@gmail.com</a>&nbsp;|&nbsp;<a href="https://twitter.com/SlaunchaMan" class="">@SlaunchaMan</a>&nbsp;|&nbsp;<a href="http://jeffkelley.org" class="">jeffkelley.org</a></div></div></span></div></div></div></div><br class=""><div><blockquote type="cite" class=""></blockquote></div></div><br class=""></body></html>