<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 Dec 21, 2017, at 11:08 PM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div 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="">I am hugely supportive of the features that these attributes enable, but I think that the spelling of this is absolutely wrong, and I’m disappointed that the extensive discussion we’ve had for months about this didn’t make it into (at least) the alternatives considered section. Here are my concerns:</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’m totally aware of your earlier e-mail thread about tying this in with availability and I briefly mentioned it in the ‘future directions’ section. I don’t have any objections to your approach and I’d be open to changing the proposal if there’s some consensus that this is the right way to go.</div><div class=""><br class=""></div><div class="">Do you think exhaustive enums should be spelled as @available(exhaustive) (or @available(exhaustive: …)), also?</div></div></div></div></div></blockquote><div><br class=""></div><div>When and if we add private cases to enums, we’ll need to be able to associate an availability range with an “exhaustive” marker. When/if that happens, then yes, we should do so through @available(exhaustive: iOS41, *). The @exhaustive attribute will become sugar for “born exhaustive”, because in the absence of private cases the availability range doesn’t matter (AFAIK).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><blockquote type="cite" class=""><div 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="">Furthermore, these two attributes are the tip of the iceberg, and the core team has spent a lot of time recently discussing the fact there are potentially going to be about a dozen attributes similar to these (fixed_contents, global_var_is_directly_addressible, …) that will only be required for binary frameworks.</div></div></blockquote><div class=""><br class=""></div><div class="">Hopefully not a dozen! But yes, there will probably be more than just the three currently under discussion.</div></div></div></div></div></blockquote><div><br class=""></div><div>This is the sort of thing that will creep over the years: lots of sorts of people care about performance, and different sorts of people have different requirements. Specific narrow features can have a huge impact on specific cases, and we should support those needs.</div><div><br class=""></div><div>Look at how many obscure attributes GCC has accreted and what a mess it is, we don’t want Swift to look like that in 15 years.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div 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="">which generalizes properly when we add version ranges:</div><div class=""><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@available(iOS 14, *) // this was introduced in iOS 14</div></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@available(linkerSymbol: iOS 15, *) // this decl’s symbol became “abiPublic" in iOS 15</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@available(inlinable: iOS 16, *) // this decl became inlinable in iOS 16</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>public func foo() {… }</div></div></blockquote><div class=""><br class=""></div><div class="">Minor nitpick: public implies ABI-public, so you probably meant the other way around, where a symbol became ABI public in iOS 14, then public in iOS 15. </div></div></div></div></div></blockquote><div><br class=""></div><div>You’re right, I got the order backward. The point stands though :-)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><div class="">This is certainly something we need to support and my understanding is the equivalent already happens all the time in Objective-C land, where SPI becomes API.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div 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="">In short, respectfully request that you at least add this approach to the "alternatives considered” section.</div></div></blockquote><br class=""></div><div class="">So, does anyone have any strong objections to Chris’s proposal?</div><div class=""><br class=""></div><div class="">From an implementation standpoint, reworking the parser to parse @available(inlinable) and @available(fixedContents) or whatever would be straightforward. I would still like to punt the version range part of this to a future proposal, though.</div></div></div></div></blockquote><br class=""></div><div>I agree. I’m only concerned that we have a direction that supports the availability ranges in a coherent way, I don’t see any urgency to actually implement them today.</div><div><br class=""></div><div>-Chris</div><div><br class=""></div><br class=""></body></html>