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

Xiaodi Wu xiaodi.wu at gmail.com
Mon Oct 2 18:42:52 CDT 2017


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/67fc4be9/attachment.html>


More information about the swift-evolution mailing list