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.
···
On Oct 3, 2017, at 12:28 AM, Andrew Trick via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 2, 2017, at 11:20 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution