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

[Nevin Brackett-Rozinsky]

On Mon, Oct 2, 2017 at 5: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.
>

Unduly restrictive is fine for now, we don’t need to make @_versioned ready
for primetime just to roll out @inlinable. We can begin with the semantics
that @inlinable functions can only call things which are themselves either
@inlinable or public, and then subsequently in the future we can expand it
to “…or whatever-we-end-up-calling- at _versioned”.

That way the scope of this proposal can stay narrow and self-contained.

Nevin



> 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/20171004/d9e2eeeb/attachment.html>