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

[Taylor Swift]

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/d09f31ad/attachment-0001.html>