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


swift-evolution mailing list

Reply via email to