> 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: >>> >>>> 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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
