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

Michael Gottesman mgottesman at apple.com
Tue Oct 3 04:35:44 CDT 2017


> On Oct 3, 2017, at 12:28 AM, Andrew Trick via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Oct 2, 2017, at 11:20 PM, Slava Pestov via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
>> 
>> Slava
> 
> FWIW, the @inlinable name has always confused me. Methods not marked @inlinable are still internally inlinable. "Inlining" is already a term of art with specific semantics in other languages, and even in Swift is it's own thing to be controlled independently from resilience. The real issue I have with the name is that it says nothing about resilience. I’ll never forget that fragility is the opposite of resilience. I can't see how a @fragile attribute would ever be misconstrued.

+1. This is exactly how I feel.

> 
> As for the various shades of fragility of data types, I don't see why that can't be handled as qualifiers or additional optional attributes for expert developers. It’s just a matter of picking a reasonable default.
> 
> -Andy
> _______________________________________________
> 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/20171003/72cb0bdb/attachment.html>


More information about the swift-evolution mailing list