> On Oct 2, 2017, at 20:23, Slava Pestov via swift-evolution > <[email protected]> wrote: > >> >> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov <[email protected] >> <mailto:[email protected]>> wrote: >> >>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma <[email protected] >>> <mailto:[email protected]>> 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. > > We have _silgen_name for that, but we really don’t want to expose this more > generally because people have been abusing it to make things visible to C, > and they should be using @_cdecl instead.
This is really not what _silgen_name is for. I suspect we'll need a mangle-as at some point that doesn't require using a full mangled name, but I don't think this is the place to introduce it. > >> >> 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? >> > > If you’re going to do that what is the value in having the capability at all? I'm actually okay with this, but it's harder to implement. Someone can come along and add it later and we'd be fine; I don't think this solution or any other has to be part of the initial proposal for it to be useful. Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
