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

Jordan Rose jordan_rose at apple.com
Tue Oct 3 13:50:48 CDT 2017



> On Oct 2, 2017, at 20:23, Slava Pestov via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>> 
>>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma <kelvin13ma at gmail.com <mailto: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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/8e00bbd4/attachment.html>


More information about the swift-evolution mailing list