> On Oct 2, 2017, at 11:20 PM, Slava Pestov <spes...@apple.com> 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.
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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
