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

[Jean-Daniel]

Look like we don’t know the same users.
I don’t know a single user that didn’t update it’s device at least once since he bought it, even if some may avoid the latest update when there device grow old though.

> Le 25 déc. 2017 à 05:46, Kelvin Ma via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> in theory this could happen but if you ask me this is such an exceedingly rare case that i don’t count much net benefit from it. most ithing users (that i know) avoid ios updates like hell but have automatic app updates turned on. so 99% of the time i would expect the app version to be more recent than the library version.
> 
> On Sun, Dec 24, 2017 at 9:59 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
> 
> 
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> why can’t we just remove inlineable functions from ABI altogether? if the argument is that app code won’t be able to take advantage of improved implementations in future library versions i don’t think that makes sense at all i would assume client code gets recompiled much more often than library code and their updates are much more likely to be downloaded by users than library updates. 
> 
> This is not necessarily true. If Swift were to ship with the OS, updating the OS might install a new Swift standard library without updating all of your apps.
> 
> Slava
> 
>> 
>> On Sun, Dec 24, 2017 at 6:04 PM, Howard Lovatt via swift-evolution <swift-evolution at swift.org <mailto: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 <>?
>> 
>> -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. 
>> 
>> Is the problem being addressed significant enough to warrant a change to Swift?
>> 
>> Yes significant but wrong solution 
>> 
>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> 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. 
>> 
>> 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. 
>> 
>> Perhaps the compiler should publish the SIL or LLVM for all public functions. Analogous to Java’s class files. This sort of system works really will, much better than C and C++. 
>> 
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>> 
>> Followed the discussions and read the proposal. The proposal doesn’t seem to encompass all the discussions. It would be nice if the proposal had a much more extensive summary of alternatives suggested. 
>> -- Howard. 
>> 
>> On 20 Dec 2017, at 7:19 pm, Ted Kremenek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> The proposal is available here:
>>> 
>>> 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>
>>> Reviews are an important part of the Swift evolution process. All review feedback should be sent to the swift-evolution mailing list at:
>>> 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> or, if you would like to keep your feedback private, directly to the review manager. 
>>> 
>>> When replying, please try to keep the proposal link at the top of the message:
>>> 
>>> 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>
>>> ...
>>> Reply text
>>> ...
>>> Other replies
>>> What goes into a review of a proposal?
>>> 
>>> The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. 
>>> 
>>> When reviewing a proposal, here are some questions to consider:
>>> 
>>> What is your evaluation of the proposal?
>>> 
>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>> 
>>> Does this proposal fit well with the feel and direction of Swift?
>>> 
>>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>> 
>>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>> 
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171225/56989d02/attachment.html>