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

[Kelvin Ma]

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> wrote:

>
>
> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
> 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> wrote:
>
>> Proposal link: 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> wrote:
>>
>> The proposal is available here:
>>
>> https://github.com/apple/swift-evolution/blob/master/proposa
>> ls/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
>>
>> 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
>> ...
>> 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
>> 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/20171224/b37f908c/attachment.html>