On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov <spes...@apple.com> wrote:
> > On Oct 2, 2017, at 7:52 PM, Kelvin Ma <kelvin1...@gmail.com> wrote: > > Is this only a problem with fileprivate or does it extend to private > members too? I feel like this would be a very valuable feature to support. > > > Private members too. Consider this example, > > struct S { > private func f() {} > } > > The member S.f mangles as > _T06struct1SV1f33_AB643CAAAE0894CD0BC8584D7CA3AD23LLyyF. > In this case, I suppose we won’t need the private discriminator because > there can only be one S.f that’s directly a member of S, and not an > extension. However imagine if two different source files both defined > extensions of S, with a private member f. You would need to disambiguate > them somehow. > The simple-minded way to do this would be to require @_versioned annotations on private and fileprivate members to supply an internally unique alternative name to be used for mangling-as-though-internal (i.e. `@_versioned(my_extension_f)`). Such a function becoming public in an ABI-compatible way would require renaming the "actual" name to the unique @_versioned name. A more elegant refinement could be to have @_versioned private and fileprivate members mangled as though internal, erroring if two or more members with the same name are both @_versioned--would that work?
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution