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

[Kelvin Ma]

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.

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

> It would be a trivial change to allow @_versioned on private and
> fileprivate declarations, but there are two pitfalls to keep in mind:
>
> - Private symbols are mangled with a ‘discriminator’ which is basically a
> hash of the file name. So now it would be part of the ABI, which seems
> fragile — you can’t move the private function to another source file, or
> rename the source file.
>
> - Similarly, right now a @_versioned function becoming public is an ABI
> compatible change. This would no longer work if you could have private
> @_versioned functions, because the symbol name would change if it became
> public.
>
> For these reasons we decided against “private versioned” as a concept. I
> feel like internal is enough here.
>
> Slava
>
>
> On Oct 2, 2017, at 4:54 PM, Taylor Swift <kelvin13ma at gmail.com> wrote:
>
> Right now @_versioned is only for internal declarations. We should have
> something similar for private and fileprivate declarations. I think most
> people use those modifiers for code organization, not binary resilience, so
> we would do well to make the two intents separate and explicit.
>
> On Mon, Oct 2, 2017 at 6:42 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>>
>> On Mon, Oct 2, 2017 at 17:41 Taylor Swift <kelvin13ma at gmail.com> wrote:
>>
>>> I think we should try to separate visibility from access control. In
>>> other words, the compiler should be able to see more than the user. I want
>>> to be able to write private and internal code that cannot be called
>>> explicitly in source, but can still be inlined by the compiler. Right now
>>> people are doing this with underscored methods and variable names but I
>>> don’t think that’s a good convention to use. We should have something at
>>> the language level that enforces that something shouldn’t be referenced by
>>> name outside of its scope, but is public for all compilation and ABI
>>> purposes. Maybe an attribute like @visible or a new keyword or something.
>>>
>>
>> Right, that’s @_versioned, essentially.
>>
>>
>> On Mon, Oct 2, 2017 at 4:45 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>> This is unduly restrictive; @_versioned (despite being the wrong
>>>> spelling) is what we want here. To be callable from an inlinable function,
>>>> internal things need only be visible in terms of public ABI, not
>>>> necessarily inlinable, just as public things need only be public and not
>>>> necessarily inlinable.
>>>> On Mon, Oct 2, 2017 at 16:37 Nevin Brackett-Rozinsky via
>>>> swift-evolution <swift-evolution at swift.org> wrote:
>>>>
>>>>> On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov <spestov at apple.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks for taking a look!
>>>>>>
>>>>>> > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <
>>>>>> nevin.brackettrozinsky at gmail.com> wrote:
>>>>>> > 3. Even though @inlinable will have no effect on declarations which
>>>>>> are not public, we should still allow it to be placed there. That way when
>>>>>> the access level is later changed to be public, the attribute is already
>>>>>> where it should be. This is similar to why we permit, eg., members of an
>>>>>> internal type to be declared public, which was discussed and decided
>>>>>> previously on Swift Evolution.
>>>>>>
>>>>>> This is an interesting point. Do you think the attribute should be
>>>>>> completely ignored, or should the restrictions on references to non-public
>>>>>> things, etc still be enforced?
>>>>>>
>>>>>
>>>>>  Hmm, good question!
>>>>>
>>>>> I rather like the idea Greg Parker put forth, where non-public
>>>>> @inlinable items can be used by public @inlinable ones, which implies that
>>>>> the restrictions should indeed still apply—something @inlinable can only
>>>>> reference public or @inlinable things.
>>>>>
>>>>> Nevin
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171002/eea52420/attachment.html>