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

Sun Dec 24 23:00:33 CST 2017

aren’t there other benefits to dynamic linking though? i’m not arguing
against dynamic linking, i’m arguing that functions that should be part of
ABI should *always* be called through the entry point and functions that
can be emitted into the client should *never* be called through the entry
point. otherwise it introduces complexity and potential bugs and internally
inconsistent behavior for no obvious benefit. the only reason inlineable
exists is for performance. a library author who marks something inlineable
and then tries to make the implementation itself more efficient is not
going to see much benefit from it just by pushing out the updated library
because no one is going to have the updated library on their device anyway.
we might as well follow Swift’s safety paradigm and make it consistent. as
for security, those functions should never have been marked inlineable to
begin with because even if a new implementation is available (and it won’t)
it doesn’t mean all the call sites will use the updated version.

On Sun, Dec 24, 2017 at 11:49 PM, Slava Pestov <spestov at apple.com> wrote:

> Sure, users download new apps more often than they download new OSes, but
> you’re basically arguing against dynamic linking at this point. If
> everything was statically linked, vendors would not be able to ship
> security updates, etc.
>
> Slava
>
>
> On Dec 24, 2017, at 8:46 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
>
> 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/p
>>> roposals/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/20171225/ad3eab47/attachment.html>