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

[Xiaodi Wu]

On Mon, Oct 2, 2017 at 22:23 Slava Pestov <spestov at apple.com> wrote:

> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> 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.
>

The difference here would be that the "@_versioned name" would be subject
to mangling. It's essentially equivalent to a way of specifying a custom
discriminator to be hashed so that the source file name is omitted and not
ABI. Not that I think it'd be elegant, but it would not be abusable like
_silgen_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?
>
>
> If you’re going to do that what is the value in having the capability at
> all?
>

Solely to have some way of preventing members in one file from calling
members in another file at compile time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/1e828a83/attachment.html>