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 

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

Reply via email to