> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov <spes...@apple.com
> <mailto:spes...@apple.com>> wrote:
>
>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma <kelvin1...@gmail.com
>> <mailto: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.
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.
>
> 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?
Slava
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
