I was making two seperate points: 1. Annotating which parts of a public APIs are stable should not be necessary and 2. Inlining should be left to the compiler.
Point 1: If you had a module system that was versioned then a public declaration should be taken as stable across all minor releases. IE You can only add public declarations, not remove or change, for versions 1.x.x compared to 1.0.0. That way you don’t need to separately annotate which bits of the API are stable. All the public API is stable. Point 2: Functions that the compiler of a module decrees are potentially inlinable should be published using SIL or LLVM so that they can be inlined when the module is used either at compile time or runtime. It is important that it is something simple like SIL or LLVM to make inlining light weight. That way the module compiler can be quite speculative about inlining and make many functions available for inlining. In contrast the compiler consuming the library can be conservative with a runtime back up if in doubt. IE if the function is marginal then don’t inline until runtime has proven that inlining is worth while. -- Howard. > On 24 Dec 2017, at 9:53 pm, Slava Pestov <spes...@apple.com> wrote: > > > >> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Proposal link: >> https://github.com/apple/swift-evolution/blob/https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.mdmaster/proposals/0193-cross-module-inlining-and-specialization.md >> What is your evaluation of the proposal? >> >> -1 >> >> The proposal puts all the emphasis on the programmer. It is better for the >> compiler to decide if something is to be inclined both across modules and >> within modules. >> >> If something is made public then it should be fixed for a given major >> version number. No need for extra annotation. >> >> A module system that allows versioning is a better solution. >> >> > Can you explain your proposed solution in more detail? > >> No, cluttering up declarations is completely against the clarity of Swift. >> For example who other than people on this group will understand >> @inline(never) @inlinable. >> >> > We don’t expect this attribute to be used frequently in third-party > frameworks. @inline(never) @inlinable is a weird combination, but I hope that > @inline(never) is used even less frequently. In fact other than debugging it > probably doesn’t have much purpose at all, and it would be nice to deprecate > it some day. >> If you have used other languages or libraries with a similar feature, how do >> you feel that this proposal compares to those? >> >> Yes C and C++ and found the equivalent of these annotations problematic. In >> Java they eliminated all this and let the compiler do the work. In practice >> this works much better. >> >> > The Java approach works because there’s no separate compilation — having a > JIT means the optimizer is free to inline across module boundaries without > any resilience considerations. This doesn’t fit with Swift’s compilation > model though. > > Slava >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
