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