<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Chris,<div class=""><br class=""></div><div class="">Thanks for reviewing the proposal!<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 11:14 PM, Chris Lattner 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 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=""><blockquote type="cite" class=""><div class="">On Dec 20, 2017, at 4:19 PM, Ted Kremenek <<a href="mailto:kremenek@apple.com" class="">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div name="messageBodySection" class="" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><p class="" style="-webkit-print-color-adjust: exact; margin-right: 0px; margin-bottom: 15px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-top: 0px !important;">The review of "SE-0193 - Cross-module inlining and specialization" begins now and runs through <strong class="" style="-webkit-print-color-adjust: exact;">January 5, 2018</strong>.</p><p class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);">The proposal is available here:</p><blockquote class="" style="margin: 5px; padding-left: 10px; border-left-width: thin; border-left-style: solid; border-left-color: rgb(26, 188, 156);"><div class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md</a></div></blockquote><p class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);">When reviewing a proposal, here are some questions to consider:</p><ul class="" style="-webkit-print-color-adjust: exact; margin: 15px 0px; padding-left: 30px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255);"><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;">What is your evaluation of the proposal?</p></li></ul></div></div></div></blockquote><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><br class=""></div><div>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><br class=""></div><div>Do you think exhaustive enums should be spelled as @available(exhaustive) (or @available(exhaustive: …)), also?</div><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="">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><br class=""></div><div>Hopefully not a dozen! But yes, there will probably be more than just the three currently under discussion.</div><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="">A minor point, but the specific name “abiPublic” is not great in my opinion, because “ABI” is a term of art for compiler hackers. Most users have no idea what ABI means, and those who think they do often don’t. Very few people really understand what “stable ABI” means for example.</div><div class=""><br class=""></div><div class="">It would be better to go with something like “apiPublic” or “symbolPublic” or “linkableButNotAccessible” or something else long. This will not be commonly used in user code, so being long and descriptive is a good thing.</div></div></blockquote><div><br class=""></div><div>Several other people in the thread also objected to the name abiPublic. I’m not attached to it and I would be open to changing it to something better. We just don’t have a clear winner yet...</div><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><br class=""></div><div>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. 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><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>So, does anyone have any strong objections to Chris’s proposal?</div><div><br class=""></div><div>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><br class=""></div><div>Slava</div><br class=""></div></body></html>