[swift-evolution] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Slava Pestov]

> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution <swift-evolution at 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 though.

Slava

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171224/956cad80/attachment.html>