> On Dec 24, 2017, at 8:33 PM, Howard Lovatt <howard.lov...@gmail.com> wrote: > > 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.
The @abiPublic attribute as described in the proposal is only meant to be used for *internal* declarations which can be referenced from inlinable functions. Public functions are not annotated, and indeed as you describe, you cannot remove any public declaration if you’re publishing a source-stable or binary-stable library. > 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. The reason the compiler cannot make the decision about what to inline across module boundaries is that this can end up exposing implementation details of the module. If everything can be inlined, you’re effectively doing static linking, which eliminates the ability to ship updated versions of a binary framework. > 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. This is already how the optimizer works today. @inlinable annotations are not necessary to inline within a module, where the compiler makes all the decisions based on cost heuristics. Across modules @inlinable does not force any inlining either, it just makes the body available for the optimizer, if it decides to make use of it. Slava > > -- Howard. > > On 24 Dec 2017, at 9:53 pm, Slava Pestov <spes...@apple.com > <mailto:spes...@apple.com>> wrote: > >> >> >>> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution >>> <swift-evolution@swift.org <mailto: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.md>https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md>master/proposals/0193-cross-module-inlining-and-specialization.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md>What >>> is your evaluation of the proposal <x-apple-data-detectors://7>? >>> >>> -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
