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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
