> On Oct 2, 2017, at 11:20 PM, Slava Pestov via swift-evolution
> <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.
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
