<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 class=""><br class=""></div><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Anyway, for my use case mentioned earlier (shipping a release version of my app bundle), that doesn’t really matter. I’d just like a compiler switch that made the whole module not having an ABI, essentially making all all methods and types @inlinable and @_versioned, using the terminology in your example.</div></div></div></blockquote><div class=""><br class=""></div>Yes, that would be a nice feature to have but it is outside the scope of this proposal. First, we want to tackle shipping resilient modules — then we can discuss generalizing the notion of a “resilience domain” to encompass multiple modules. I realize the latter is more useful to third party developers though, and I apologize that in this particular case our priorities are at odds…</div></blockquote><div class=""><br class=""></div><div class="">If a framework is only ever used by a single client in the app bundle, as it is in the majority of cases, I think the objective should be to link it statically. The dynamic linking overhead is useless in this case. Would this allow the compiler to optimize across module boundaries? (Are the current capabilities of Xcode 9 in this regard described anywhere?) </div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); 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;">Elia Cereda</div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Il giorno 04 ott 2017, alle ore 08:09, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> ha scritto:</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=""><br class="Apple-interchange-newline"><br class=""><blockquote type="cite" class=""><div class="">On Oct 3, 2017, at 11:05 PM, Jonas B <<a href="mailto:bobergj@gmail.com" class="">bobergj@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 4 Oct 2017, at 14:33, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space;"><br class=""><div class="">@_versioned makes a symbol visible externally without making it visible from the language. There is no requirement that a @_versioned thing is @inlinable. It is used when you want to reference an internal function from an inlinable function. Eg,</div><div class=""><br class=""></div><div class="">internal func myImplDetail() { … }</div><div class=""><br class=""></div><div class="">@inlinable public func myPublicFunction() { myImplDetail() } // error!</div><div class=""><br class=""></div><div class="">—</div><div class=""><br class=""></div><div class=""><div class="">@_versioned internal func myImplDetail() { … }</div><div class=""><br class=""></div><div class="">@inlinable public func myPublicFunction() { myImplDetail() } // OK</div></div><div class=""><br class=""></div><div class="">Slava</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">From my language user point of view it would be more understandable if that was written with a single keyword, eg:</div><div class="">@nonABI internal func myImplDetail() { }</div><div class="">@nonABI public func myPublicFunction() { myImplDetail() } // OK</div></div></div></blockquote><div class=""><br class=""></div>The two attributes are different though. myImplDetail() is _not_ inlined into client code here, but myPublicFunction() is. So they need different attributes to express this intent.</div><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=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">Anyway, for my use case mentioned earlier (shipping a release version of my app bundle), that doesn’t really matter. I’d just like a compiler switch that made the whole module not having an ABI, essentially making all all methods and types @inlinable and @_versioned, using the terminology in your example.</div></div></div></blockquote><div class=""><br class=""></div>Yes, that would be a nice feature to have but it is outside the scope of this proposal. First, we want to tackle shipping resilient modules — then we can discuss generalizing the notion of a “resilience domain” to encompass multiple modules. I realize the latter is more useful to third party developers though, and I apologize that in this particular case our priorities are at odds…</div><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=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">My other observation is that no matter how great the ergonomics, and no matter the naming of these attributes, very few people outside the compiler team is going to be able to successfully ship a versioned library without the “Checking Binary Compatibility” tool mentioned in <a href="https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility" class="">https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#checking-binary-compatibility</a>.</div></div></div></blockquote><div class=""><br class=""></div>I agree — even for members of the compiler team this tool would be very useful, both as a way of encoding our assumptions for sanity-checking, and making sure we don’t make a silly mistake with a future update to the standard library.</div><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=""><br class=""></div><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="">Slava</div><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=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">/Jonas</div><div class=""><br class=""></div></div></div></blockquote></div><br class="" 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;"><span 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; float: none; display: inline !important;" class="">_______________________________________________</span><br 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=""><span 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br 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=""><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="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=""><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=""></body></html>