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

[Chris Lattner]

> On Oct 2, 2017, at 11:20 PM, Slava Pestov <spestov at apple.com> wrote:
> 
> 
>> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> This semantic doesn’t make sense to me, and I think we need to change it.  I think we are better served with the semantics of “the body may be inlined, but doesn’t have to.”
>> 
>> That is the effect it has today. The decision to inline or not is made by the optimizer, and @inlinable doesn’t change anything here; it makes the body available if the optimizer chooses to do so.
> 
> Also remember we have the @inline(never) attribute. It’s not underscored so I’m assuming it’s an “official” part of the language. And "@inline(never) @inlinable" is a perfectly valid combination — it serializes the SIL for the function body, and while inlining it is prohibited, it is still subject to specialization, function signature optimizations, etc.

Despite the underscore, I don’t think that this was officially ever “design reviewed”, and I don’t think it is widely used.  If we need to change or restrict or add requirements to @inline(never), we can do so IMO.  We can design adequate upgrade paths and keep the old behavior around for compatibility if necessary.  Lets focus on what the right long term model is.

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171003/d2514770/attachment.html>