<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="" applecontenteditable="true"><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 14, 2017, at 10:41 AM, Jeff Kelley via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On Mon, Feb 13, 2017 at 11:53 PM, Rod Brown<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:rodney.brown6@icloud.com" target="_blank" class="">rodney.brown6@icloud.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div class="">I think the biggest problem we're going to face with this one is changes to Objective-C are out of scope for Swift Evolution. Apple tend to be the ones in control of the development of new Objective-C features and compatibility because they control the compiler.</div></div></blockquote><div class=""><br class=""></div><div class="">I don’t think that Objective-C changes are out of bounds when Swift is involved—see my past, accepted proposal at<span class="Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md" class="">SE-0033</a>.</div></div></div></div></div></blockquote><div><br class=""></div><div>For this kind of change to have a real impact, it needs to affect a significant number of frameworks that Swift programmers use. Unless there are automatic heuristics that are *very good*, doing so requires a large amount of manual labor and coordination. So while it is true that Objective-C changes can be in-bounds, from a prioritization/impact perspective, they might not be the right thing to focus on.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div dir="auto" class=""><div id="gmail-m_-8936043654950753604AppleMailSignature" class="">That said, as a request to Apple for this change, I think it's a reasonable idea for Ints, but I'm not sure of its feasibility for other types. Could the API be descriptive enough to cover enough types? (Eg CGRectNull)<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">It’s an open-and-shut case for any standard primitive, but structs like<span class="Apple-converted-space"> </span><font face="monospace, monospace" class="">CGRect</font><span class="Apple-converted-space"> </span>are where it starts to get tricky. I see that<span class="Apple-converted-space"> </span><font face="monospace, monospace" class="">CGRect</font><span class="Apple-converted-space"> </span>conforms to<span class="Apple-converted-space"> </span><font face="monospace, monospace" class="">Equatable</font><span class="Apple-converted-space"> </span>when it’s imported into Swift; perhaps that could be enough for this to work? If the translation to and from<span class="Apple-converted-space"> </span><font face="monospace, monospace" class="">nil</font><span class="Apple-converted-space"> </span>happens in the Swift side, I can see<span class="Apple-converted-space"> </span><font face="monospace, monospace" class="">Equatable</font><span class="Apple-converted-space"> </span>as a reasonable requirement for the type.</div></div></div></div></div></blockquote><br class=""></div><div>In the most general case, one could imagine providing the names of a pair of C functions to the annotation: one answers the question “is this a nil value?” and the other can be called to produce a nil value.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>