<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="">I was going to write up a detailed response to this as well, but Chris did it for me.<div class=""><br class=""></div><div class="">In general, I agree that we need the feature.</div><div class=""><br class=""></div><div class="">However, I believe that the name “ABI” is too specific and does not accomplish the primary purpose of naming this thing — which is to allow people to understand what it means by reading it.</div><div class=""><br class=""></div><div class="">I agree that scoping these attributes inside the availability declaration is the best option. As a framework author, the notion of availability is of primary importance, and having things which affect how my clients see my code be part of that general concept makes the most sense. My second choice would be to scope it inside the “public” declaration, as in:</div><div class=""><br class=""></div><div class="">public</div><div class="">public(inlinable)</div><div class="">public(external) // *where we define external to be what abiPublic is now — more bike shedding welcome</div><div class=""><br class=""></div><div class="">- Tony<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="caret-color: rgb(0, 0, 0); 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; text-decoration: none;" 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 class=""><br class=""></div><div class=""><b class="">Availability Ranges</b></div><div class=""><br class=""></div><div class="">Both of these attributes will (perhaps not for Swift 5 given the fact that these will be new then, but certainly in 5.1 or 6) need to be qualified by deployment modifiers. We’ll need the ability to specify not just that a declaration is inlinable or abipublic, but in *which versions* of the binary package (that they are defined in) have this property. </div><div class=""><br class=""></div><div class="">For example, while perhaps it will be common for a decl to be “born inlinable” and just need the form of attribute as specified here, it is just as clear that this is not the *only* model we need. It is entirely reasonable (and will be important in the future) to say that something “became ABI public in iOS14, became abiPublic in iOS 15, and became inlinable in iOS16”. The use of this will be relatively rare, but it is important for the model to support this in time.</div><div class=""><br class=""></div><div class="">Because of this, if we accept the spelling as proposed in this proposal, these attributes will need to be generalized to have an availability range, e.g.:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@abipublic(iOS 15, *)</div><div class=""><br class=""></div><div class="">The concern is that this proposal opens the door to have a family of attributes each of which have availability information on them, and this “family” of attributes will have nothing tying them together into a unified framework.</div><div class=""><b class=""><br class=""></b></div><div class=""><b class=""><br class=""></b></div><div class=""><b class="">Pollution of the Attribute Namespace</b></div><div class=""><br class=""></div><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. It is possible that @inlinable will be prominent enough to be a global attribute (I personally am not sure if it will be commonly used or not, it depends a lot on how widely used binary frameworks are). That said, it is clear @abiPublic will not be commonly used, and many attributes that follow these will be even more obscure.</div><div class=""><br class=""></div><div class="">This is bad for three reasons: </div><div class=""><br class=""></div><div class="">1) we’re polluting the general attribute namespace with obscure things. Pollution of the attribute namespace may have a marginal impact today, but will start to matter if/when we ever get user defined attributes. </div><div class=""><br class=""></div><div class="">2) The other reason is that this provides no general framework to tie together these things that affect binary frameworks into a unified framework. </div><div class=""><br class=""></div><div class="">3) Furthermore, I don’t like attributes being a dumping ground for weird performance hacks required by binary frameworks. It is a practical necessity that we support these because they are extremely important for narrow cases, but we don’t need to put them into a syntactically prominent spot in the grammar.</div><div class=""><br class=""></div><div class=""><b class="">The name “ABI”</b></div><div class=""><br class=""></div><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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Counterproposal:</b></div><div class=""><br class=""></div><div class="">There is a simple way to address the two concerns above: we already have a framework for handling API evolution with binary frameworks, the @available attribute. We can spell these “attributes” as:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@available(inlinable) // this symbol has been inlinable since it was introduced</div><div class=""><br class=""></div><div class="">which generalizes properly when we add version ranges:</div><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 class=""><br class=""></div><div class="">and allows us to bury weird hacks like “abiPublic” and the other even more obscure things that are coming outside of the global attribute namespace:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@available(global_var_is_directly_accessible: iOS 15, *)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>public var myDispatchOnceToken : ...</div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Given this unified framework for handling ABI evolution, we can then separately discuss which ones of these proposals are common and important enough to sugar into a top level attribute. For example, given the general model for inlinable above, we could then (possibly as a later proposal) introduce:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@inlinable // this symbol has been inlinable since it was introduced</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>public func foo() </div><div class=""><br class=""></div><div class="">as sugar for:</div><div class=""><br class=""></div><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>@available(inlinable)</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>public func foo() </div><div class=""><br class=""></div><div class="">… which means that the sugar forms can be separately debated, and that the sugar forms don’t have to permit the full complexity of the general case (the availability list). It still isn’t clear to me whether @inlinable meets the bar to be a global attribute, I can see both sides of that argument, and it seems valuable to be able to separate the engineering work to introduce the feature from the bikeshed discussion about whether it should be sugared or not.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">In short, respectfully request that you at least add this approach to the "alternatives considered” section. I also suggest you strongly consider pursuing this direction. It solves the same problem as your proposal but:</div><div class=""><br class=""></div><div class="">- scales better as we add more “attributes" in the future - which will be of increasingly narrow applicability.</div><div class="">- provides a unifying model for all of the binary framework hints</div><div class="">- puts all the availability markup into the feature we already have for this.</div><div class="">- provides a better naming framework for things like abiPublic, because you can say "@available(linkerSymbol)” to say that this is making the linker symbol available from the binary framework.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div name="messageBodySection" class="" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><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;"></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;">Is the problem being addressed significant enough to warrant a change to Swift?</p></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;">Does this proposal fit well with the feel and direction of Swift?</p></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</p></li><li class="" style="-webkit-print-color-adjust: exact; margin: 0px;"><p class="" style="-webkit-print-color-adjust: exact; margin: 0px 0px 15px;">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</p></li></ul><p class="" style="-webkit-print-color-adjust: exact; margin-top: 15px; margin-right: 0px; margin-left: 0px; font-family: Helvetica, arial, sans-serif; background-color: rgb(255, 255, 255); margin-bottom: 0px !important;">Thanks,<br class="" style="-webkit-print-color-adjust: exact;">Ted Kremenek<br class="" style="-webkit-print-color-adjust: exact;">Review Manager</p></div><div name="messageReplySection" class="" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br class=""><div class=""></div></div></div>_______________________________________________<br class="">swift-evolution-announce mailing list<br class=""><a href="mailto:swift-evolution-announce@swift.org" class="">swift-evolution-announce@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution-announce" class="">https://lists.swift.org/mailman/listinfo/swift-evolution-announce</a><br class=""></div></blockquote></div><br class="" style="caret-color: rgb(0, 0, 0); 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; text-decoration: none;"><span style="caret-color: rgb(0, 0, 0); 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; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); 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; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); 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; text-decoration: none; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="caret-color: rgb(0, 0, 0); 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; text-decoration: none;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="caret-color: rgb(0, 0, 0); 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; text-decoration: none;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></div></body></html>