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

[Slava Pestov]

Thanks for taking a look!

> On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com> wrote:
> 
> I am hugely in favor of an @inlinable attribute, and I look forward to its arrival with relish!
> 
> Some feedback:
> 
> 1. I think “inlinable” is the right spelling: it indicates that something is *able* to be inlined.

Yeah, it seems this is the spelling we’re going to go with.

> 
> 2. If I want to pass an @inlinable function as an argument (say, to map or filter) can I do so directly or must I use a closure which calls the inlinable function?

You can pass it directly. From the viewpoint of code that uses an inlinable function, it behaves exactly the same as one that does not have the attribute.

> 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?

Slava

> 
> Other than that the proposal looks great, thanks for writing it up.
> 
> Nevin