[swift-evolution] Pitch: Cross-module inlining and specialization

[Xiaodi Wu]

On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov <spestov at apple.com> wrote:

>
> On Oct 2, 2017, at 7:52 PM, Kelvin Ma <kelvin13ma at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171002/2467be27/attachment.html>