Thanks for the review! > On Oct 2, 2017, at 10:57 PM, Chris Lattner <clatt...@nondot.org> wrote: > > This is a great proposal, I’m a strong supporter, but have one question and > one strong push back: > >> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Introduction >> We propose introducing an @inlinable attribute which exports the body of a >> function as part of a module's interface, making it available to the >> optimizer when referenced from other modules. >> > The major question I have is “why yet another attribute”. The thread about > exhaustive/extensible enums is similarly proposing introducing another > one-off way to be enums fragile, and this is directly related just for > function-like things. > > I’d love to see rationale in the proposal for why you’re not taking this in > one of these directions: > > 1) Why not another level of access control? There is a reasonable argument > that what you’re doing is making something “more public than public” or that > you’re making the “body also public”. I’m not strongly in favor of this > design approach, but if you agree, the doc should explain why you’re not in > favor of it. > > 2) Why can’t we have a single Swift-wide concept that unifies all of the > resilience ideas under a single umbrella like “fragile” - which indicates > that the body of a declaration is knowable to clients? There is a very > reasonable holistic design where “fragile public func” makes its body > inlinable, and “fragile enum” similarly makes the cases knowable to the > client (thus making exhaustive switching a possibility). I am strongly in > favor of this approach. > > > 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. 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. 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. > 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. > 2) there are lots of reasons why the compiler may not *want* to inline the > body of a declaration, including wanting fast debug builds, “optimizing for > size” builds, or cost heuristics that lead the compiler to believe that there > is no gain for inlining the body of a function in some context. Right. > 3) If the symbol is always guaranteed to be present, adding @inlinable is an > ABI preserving change. I think that this is also really important because it > reflects a natural evolution of code: in R1 of a module’s public release, a > symbol my be public, but after numerous releases, it may be decided that it > is stable enough to make “inlinable”. > > 4) Certain declarations *have* to be emitted anyway, e.g. an @inlinable open > method on a class can’t actually be inlined in most cases, because the call > is dynamicly dispatched. Yes. The function is still emitted into the library, but the symbol does not have public linkage. If we make the change to give the attribute ‘always emit into client’ semantics, a client can still reference the function without inlining it, for whatever reason, either because it cannot be (you’re using the function as a value) or the optimizer decides that it is not profitable to inline it. However the client binary would have to emit its own copy of the function (again, with non-public linkage). >> We have discussed adding a "versioned @inlinable" variant that preserves the >> public entry point for older clients, while making the declaration inlinable >> for newer clients. This will likely be a separate proposal and discussion. >> > 5) It eliminates this complexity. Yeah. In fact the current implementation of @inlinable does not change the function’s linkage — it remains public. It just enables SIL serialization for the body. I recall the standard library folks had good reasons to prefer the ‘always emit into client’ behavior though; maybe Jordan or Dave can explain. > > >> Comparison with other languages >> The closest language feature to the @inlinable attribute is found in C and >> C++. In C and C++, the concept of a header file is similar to Swift's binary >> swiftmodule files, except they are written by hand and not generated by the >> compiler. Swift's public declarations are roughly analogous to declarations >> whose prototypes appear in a header file. >> >> Header files mostly contain declarations without bodies, but can also >> declare static inlinefunctions with bodies. Such functions are not part of >> the binary interface of the library, and are instead emitted into client >> code when referenced. As with @inlinable declarations, static >> inlinefunctions can only reference other "public" declarations, that is, >> those that are defined in other header files. >> > The writing should be clarified, because there are multiple concepts going on > here, including GNU89’s notion of inline, C99’s notion of inline (aka extern > inline), and static inline, each with overlapping but and confusingly > different semantics. Can you suggest some better wording for this section? I admit I don’t know C very well compared to some of you here, having never implemented my own C compiler or participated in standards committee. :-) Slava > > -Chris > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
