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

[Chris Lattner]

On Oct 2, 2017, at 11:11 PM, Slava Pestov <spestov at apple.com> wrote:
>> In any case, even if you’re opposed to these approaches, I’d love for the “alternatives considered” section to indicate what the objection is.  I am really very concerned that you’re causing a keyword/attribute explosion and conceptual complexity by adding too many small things to individual parts of the language.  We would ideally have a simple and holistic solution to resilience.
> 
> I agree with that keyword/attribute explosion is a concern. We also plan on submitting a proposal to add a @fixedContents attribute for structs (currently implemented as @_fixed_layout) which enables more efficient access patterns in resilient code, for example direct access of stored properties, at the cost of preventing new stored properties from being added in a binary-compatible manner. So we would have ‘nonexhaustive’ enums, @fixedContents structs, and @inlinable functions/properties/initializers.

Yes, and then we’ll need something else for classes as well (*head explodes*).

I really prefer having a single “fragile” concept, and allowing it to be parameterized for declarations that can be fragile in different ways: "fragile(storage) class Foo” or whatever.

> Perhaps it makes sense to have a single ‘fragile’ keyword replace @fixedContents and @inlinable. For enums, ‘nonexhaustive’ does “feel” a bit different, so perhaps it makes sense for it to be its own thing.

The core team discussed enums about a year ago and my recollection was that we came to the decision that there was “c style fragility” and “non-fragility” that were the only interesting points on the spectrum.  Intermediate points like saying that "the list of members can be fixed, but their enum values were not” was deemed to be only of academic curiosity.  If we ever had a compelling use-case for such a thing, we could parameterize fragile to support it.

> From an implementation perspective it doesn’t really matter if we have multiple attributes or one, so of course I’d prefer to go with the approach that makes the most sense to people language design-wise.

Yes, I’m only concerned with the user visible design here.  Internally implementing these things as a matrix of capabilities is entirely sensible, but not the purview of swift-evolution.

>> 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.

If I read the proposal correctly, it is saying that the body has to be inlined into the modules that use it, because there is no symbol published from the module that defines it.  That’s the concept of inlining that I’m objecting to.

-Chris