On Thu, Dec 21, 2017 at 12:26 AM, Slava Pestov <spes...@apple.com> wrote:

> Thanks for the review, Kelvin.
> On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution <
> swift-evolution@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.
> Slava
i understand that but i also feel like that’s a completely solvable problem
if someone put in some effort to look into it. right now i think
fileprivate is the only problematic keyword with this since i think
changing the name of a private type makes a lot more sense that it would
break abi than renaming a file would. but it’s also the least used so
that’s a plus.
swift-evolution mailing list

Reply via email to