[swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

Slava Pestov spestov at apple.com
Thu Dec 21 00:26:33 CST 2017

Thanks for the review, Kelvin.

> On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org> wrote:
> it makes sense to have @abiPublic on private and fileprivate declarations too and i hope this gets added, because private and fileprivate are tools for code organization and maintenance,, the compiler with wmo doesn’t care about private vs internal. but @abiPublic private is bound to cause confusion and it just reads funny. 

From an implementation standpoint, it would be a simple change to allow @abiPublic on private and fileprivate declarations. However, I think that introduce some confusion. Recall that the mangling of private symbols includes the source file name. This would now be part of your framework’s ABI. If you moved the @abiPublic function to another source file, or rename the source file, you will break ABI.

Another approach would be to change the mangling so that @abiPublic private symbols are mangled like internal symbols, with a module name and no source file name. This makes for a simpler ABI. However this also has a downside, because now if you define two @abiPublic private functions in different files that have the same mangling, you will get a linker error and not a nice compiler diagnostic.

Note that nothing in this proposal precludes @abiPublic from being applied to private and fileprivate symbols though. If we figure out a nice solution to the above problems, we could generalize @abiPublic without any issues.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/136a6431/attachment.html>

More information about the swift-evolution mailing list