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

[Kelvin Ma via swift-evolution]

that’s why i keep saying we should separate human-facing encapsulation
concepts from compiler-facing abi visibility concepts. i’ve always been
advocating for something like

internal(visible)
fileprivate(visible)
private(visible)

in the same spelling we currently use for stuff like private(set). we might
have to disallow it for fileprivate because of the name mangling issue that
Slava mentioned but it’s an elegant spelling and extensible if someone
comes up with a good unique mangling scheme for private declarations.

On Fri, Dec 29, 2017 at 10:35 AM, Félix Cloutier via swift-evolution <
swift-evolution@swift.org> wrote:

> I agree with the common theme that `@abiPublic` is weird. I imagine that
> not a lot of `@abiPublic` symbols actually want to be internal: they'll
> almost all be implementation details that really want to be `private` or
> `fileprivate` but that have to be `internal` to satisfy what (I believe)
> most people would consider to be a leaky abstraction provided by the Swift
> language. So why not go all the way and force @inlinable code to only
> reference public declarations?
>
> What do we get in exchange of subverting the thus-far clear meaning of
> `internal`? Why is it better to have a special kind of internal that is not
> internal, instead of a special kind of public that is not listed, or even
> just no special kind of public?
>
> That detail aside, having the ability to do cross-module inlining and
> specializing is valuable and exciting.
>
> Félix
>
> Le 20 déc. 2017 à 19:19, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
> 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
>
> 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?
>
> Thanks,
> Ted Kremenek
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

I agree with the common theme that `@abiPublic` is weird. I imagine that not a 
lot of `@abiPublic` symbols actually want to be internal: they'll almost all be 
implementation details that really want to be `private` or `fileprivate` but 
that have to be `internal` to satisfy what (I believe) most people would 
consider to be a leaky abstraction provided by the Swift language. So why not 
go all the way and force @inlinable code to only reference public declarations?

What do we get in exchange of subverting the thus-far clear meaning of 
`internal`? Why is it better to have a special kind of internal that is not 
internal, instead of a special kind of public that is not listed, or even just 
no special kind of public?

That detail aside, having the ability to do cross-module inlining and 
specializing is valuable and exciting.

Félix

> Le 20 déc. 2017 à 19:19, Ted Kremenek via swift-evolution 
>  a écrit :
> 
> The review of "SE-0193 - Cross-module inlining and specialization" begins now 
> and runs through January 5, 2018.
> 
> The proposal is available here:
> 
> 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
> 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?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

yeah among people i know most ios updates are accidental. unless you count
the one time my friend updated because her phone automatically downloaded
the iso and it was taking up like 5 gb and she had no space left. the last
times i remember anyone willingly updating their iphone was the ios7 update
and the one that gave us all the new emojis. personally mine’s been
pestering me about ios 11.2.1 for a long ass time and i’m actually
relatively good about updating ios because people don’t get the echo text
effect when i send it. also i’m sure the apple slowing down old iphones
news isn’t helping much lol

On Mon, Dec 25, 2017 at 4:19 AM, Jean-Daniel  wrote:

> 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@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  wrote:
>
>>
>>
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@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@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@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-

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

[Jean-Daniel via swift-evolution]

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 
>  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  > wrote:
> 
> 
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution 
>> > 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 
>> > 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 
>> > wrote:
>> 
>>> The proposal is available here:
>>> 
>>> 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 
>>> 
>>> 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 

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

[Kelvin Ma via swift-evolution]

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  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  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  wrote:
>
>>
>>
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@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@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@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 

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

[Slava Pestov via swift-evolution]

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  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  > wrote:
> 
> 
>> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution 
>> > 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 
>> > 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 
>> > wrote:
>> 
>>> The proposal is available here:
>>> 
>>> 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 
>>> 
>>> 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 

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

[Slava Pestov via swift-evolution]

> On Dec 24, 2017, at 8:33 PM, Howard Lovatt  wrote:
> 
> I was making two seperate points: 1. Annotating which parts of a public APIs 
> are stable should not be necessary and 2. Inlining should be left to the 
> compiler. 
> 
> Point 1: If you had a module system that was versioned then a public 
> declaration should be taken as stable across all minor releases. IE You can 
> only add public declarations, not remove or change, for versions 1.x.x 
> compared to 1.0.0. 
> 
> That way you don’t need to separately annotate which bits of the API are 
> stable. All the public API is stable. 

The @abiPublic attribute as described in the proposal is only meant to be used 
for *internal* declarations which can be referenced from inlinable functions. 
Public functions are not annotated, and indeed as you describe, you cannot 
remove any public declaration if you’re publishing a source-stable or 
binary-stable library.

> Point 2: Functions that the compiler of a module decrees are potentially 
> inlinable should be published using SIL or LLVM so that they can be inlined 
> when the module is used either at compile time or runtime.

The reason the compiler cannot make the decision about what to inline across 
module boundaries is that this can end up exposing implementation details of 
the module. If everything can be inlined, you’re effectively doing static 
linking, which eliminates the ability to ship updated versions of a binary 
framework.

> It is important that it is something simple like SIL or LLVM to make inlining 
> light weight. That way the module compiler can be quite speculative about 
> inlining and make many functions available for inlining. In contrast the 
> compiler consuming the library can be conservative with a runtime back up if 
> in doubt. IE if the function is marginal then don’t inline until runtime has 
> proven that inlining is worth while. 

This is already how the optimizer works today. @inlinable annotations are not 
necessary to inline within a module, where the compiler makes all the decisions 
based on cost heuristics. Across modules @inlinable does not force any inlining 
either, it just makes the body available for the optimizer, if it decides to 
make use of it.

Slava

> 
> -- Howard. 
> 
> On 24 Dec 2017, at 9:53 pm, Slava Pestov  > wrote:
> 
>> 
>> 
>>> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution 
>>> > wrote:
>>> 
>>> Proposal link: https://github.com/apple/swift-evolution/blob/ 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>>>  
>>> 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. 
>>> 
>>> 
>> 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
>> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

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

>
>
> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution <
> swift-evolution@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@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@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> 

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

[Howard Lovatt via swift-evolution]

I was making two seperate points: 1. Annotating which parts of a public APIs 
are stable should not be necessary and 2. Inlining should be left to the 
compiler. 

Point 1: If you had a module system that was versioned then a public 
declaration should be taken as stable across all minor releases. IE You can 
only add public declarations, not remove or change, for versions 1.x.x compared 
to 1.0.0. 

That way you don’t need to separately annotate which bits of the API are 
stable. All the public API is stable. 

Point 2: Functions that the compiler of a module decrees are potentially 
inlinable should be published using SIL or LLVM so that they can be inlined 
when the module is used either at compile time or runtime. It is important that 
it is something simple like SIL or LLVM to make inlining light weight. That way 
the module compiler can be quite speculative about inlining and make many 
functions available for inlining. In contrast the compiler consuming the 
library can be conservative with a runtime back up if in doubt. IE if the 
function is marginal then don’t inline until runtime has proven that inlining 
is worth while. 

-- Howard. 

> On 24 Dec 2017, at 9:53 pm, Slava Pestov  wrote:
> 
> 
> 
>> On Dec 24, 2017, at 3:04 PM, Howard Lovatt via swift-evolution 
>>  wrote:
>> 
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.mdmaster/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. 
>> 
>> 
> 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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 24, 2017, at 4:00 PM, Kelvin Ma via swift-evolution 
>  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 
> > 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 
> > wrote:
> 
>> The proposal is available here:
>> 
>> 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 
>> 
>> 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@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 
> ___
> swift-evolution mailing list
> 

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

[Slava Pestov via swift-evolution]

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

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.

On Sun, Dec 24, 2017 at 6: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
>
>-
>
>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@swift.org> wrote:
>
> The proposal is available here:
>
> 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
>
> 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Howard Lovatt via swift-evolution]

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 
>  wrote:
> 
> The proposal is available here:
> 
> 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
> 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 22, 2017, at 1:50 AM, Johannes Weiß  wrote:
> 
> totally agree that these attributes are necessary, they should be in Swift as 
> soon as we bike shedded the right name. But to prevent them from being placed 
> everywhere without thinking I propose to introduce a compiler mode at the 
> same time.
> Performance testing is hard and takes time. So I'm pretty sure that as soon 
> as one @abiPublic/@inlinable has proven to improve performance, library 
> authors will just start putting them anywhere as there's no downside besides 
> making the code harder to read.
> 
> What is the downside of bringing the attributes and the compiler mode at the 
> same time. Am I massively underestimating the amount of work required for 
> such mode?

ABI stability for the standard library is our top priority for Swift 5. While 
adding a ‘completely fragile’ compiler mode should be straightforward in 
theory, the devil is in the details, and I don’t think we can commit to 
delivering this feature any time soon.

> Cool. Just to be sure I understand you correctly: Assuming your proposal gets 
> implemented as proposed, a function that does _not_ have the @inlinable 
> attribute it won't be specialised across modules, ever. Correct?

That is correct. This is already the behavior today, so there’s no change here.

Slava___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

> On Dec 22, 2017, at 1:29 AM, Slava Pestov  wrote:
> 
>> On Dec 21, 2017, at 12:42 PM, Paul Cantrell > > wrote:
>> 
>> 1. Presumably the portions of A inlined into B and C remain sensitive to the 
>> version-specific memory layout of A? Or will ABI stability mean that the 
>> compiler can magically rearrange memory offsets in already-compiled code 
>> when the layout changes? (Apologies if this is a too-obvious question; this 
>> part of Swift is all a mystery to me.)
> 
> There is not really a notion of memory layout at the level of an entire 
> module. For structs, classes and enums, you pretty much have the same 
> concerns with both inlinable and non-inlinable functions — if the framework 
> author can change the stored property layout of a struct or class (or adds a 
> case to an enum), code that manipulates these data types must not make any 
> compile-time assumptions that might be invalidated at runtime with a newer 
> version of the framework.
> 
> This is basically what the upcoming @fixedContents proposal for structs is 
> about — giving framework authors a way to trade future flexibility for 
> performance by allowing the compiler to make assumptions about the layout of 
> a struct as it is written at compile-time. The @exhaustive proposal for enums 
> has a similar implementation angle, but is of course more interesting because 
> it affects the source language as well, with switch statements.
> 
> We don’t plan on any kind of resilience opt-out for classes — already in 
> shipping Swift compilers, accesses to stored properties of classes use 
> accessor methods and not direct access across module boundaries.

Thanks, this is quite helpful.

My underlying concern here is that understanding even what kinds of breakage 
are _possible_ due to inlining currently requires fairly detailed knowledge of 
Swift’s guts, and even the best-intentioned among us are going to get it wrong. 
We’ll need tool help reasoning about it, not just documentation. At least I 
know _I_ will! (Actually, I’ll probably just avoid @inlinable altogether, but 
I’d certainly need tool help if I ever do use it.)

> 
>> 2. Is there some class of statically identifiable breaking changes that the 
>> compiler does (or should) detect to flag incompatible inlined code? e.g. 
>> some version of A inlined into B references A.foo, then A.foo is deleted in 
>> a later version of A, so mixing older B with newer A in a project gives a 
>> compile- or link-time error?
> 
> This is what an “ABI differ” tool would achieve, but like I said it has not 
> yet been designed.

Yes. I would certainly use such a tool if it existed, and not just for dealing 
with @inlinable.

> 
>> 3. Does this need some sort of poison pill feature for other sorts of 
>> breaking changes that are not statically detectable? e.g. invariants of a 
>> data structure in A change in release 2.0, so the author of A says “it is an 
>> error to include A ≥2.0 in any project that inlined any of my code from a 
>> version <2.0.” Is this what you were getting at with the mention of 
>> @inlinable(2.0) in the proposal? Sounded like that part was about something 
>> else, but I didn’t really grasp it tbh.
> 
> This is an interesting point and I think it is outside of the scope of these 
> proposals. If the ABI of a library changes in an incompatible manner and 
> previous binaries are no longer compatible with it, you should think of it as 
> shipping a *new* library, either by changing it’s name or bumping the major 
> version number, so that the dynamic linker prevents the client binary from 
> being run in the first place.

If the compiler/linker actively prohibits mixing of inlined code from different 
major version numbers, that eases my concern somewhat. A library author isn’t 
stuck with an ABI-sensitive mistake until the end of time.

> 
>> Yes, frameworks+app built simultaneously are clearly the more common case. 
>> Though Carthage seems to be champing at the bit to create this problem, 
>> since it added a feature to download prebuilt binaries long before ABI 
>> stability! I can easily imagining this feature spreading via word of mouth 
>> as a “secret go faster switch,” and causing no end of problems in the wild.
> 
> Perhaps, but I still think it is strictly better to formalize the feature 
> through a proposal and document the pitfalls carefully — the underscored 
> attribute is already spreading through word of mouth and in the absence of 
> official documentation the potential for abuse is greater.

Fair point. Making this feature public & documented, albeit ill understood, is 
a safety improvement over undocumented & even iller-understood!

> 
>> It might be safer — and better match the understanding of the typical user — 
>> to have @inlinable assume by default that an inlined version of any given 
>> method is only valid only for the specific version of the module it was 
>> inlined from. 

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

[Johannes Weiß via swift-evolution]

Hi Slava,

> On 22 Dec 2017, at 7:13 am, Slava Pestov  wrote:
> 
> Hi Johannes,
> 
> Thanks for reviewing this proposal!
> 
>> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>>  wrote:
> 
>> The library I'm working on will presumably never have stable ABI as you'd 
>> naturally build it with your application. However we also don't want to miss 
>> on the cross-module optimisation & specialisation and I suspect there are 
>> quite a few (mostly open-source) libraries in the same space. I'm pretty 
>> sure everybody would just end up littering their code with 
>> @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) 
>> without actually meaning that.
>> 
>> Summing up: I think this feature is crucial but shouldn't come without a 
>> compiler "where all declarations become implicitly @inlinable, and all 
>> private and internal declarations become @abiPublic". I really don't want to 
>> litter the code with attributes that aren't what I mean. (basically `swift 
>> build --global-resilience-domain`) Having this compiler mode also makes 
>> these attributes IMHO really niche and therefore I can only sympathise 
>> with's Chris' sentiment to not litter the global attribute namespace.
> 
> I agree that a ‘completely non-resilient’ compiler mode would be great when 
> building libraries that are always shipped together, and I hope Swift gains 
> such a feature one day, possibly built on top of the very infrastructure used 
> to implement this proposal!

Cool. I just meant that the compiler mode and the public (as in 
non-underscored) attributes should go hand in hand to not tempt people into 
littering their code without thinking.


> However, the goal of this proposal is to formalize some language features 
> that already exist and are used by the standard library. Clearly making 
> everything fragile is a non-starter for the standard library in an ABI-stable 
> world.

totally agree that these attributes are necessary, they should be in Swift as 
soon as we bike shedded the right name. But to prevent them from being placed 
everywhere without thinking I propose to introduce a compiler mode at the same 
time.
Performance testing is hard and takes time. So I'm pretty sure that as soon as 
one @abiPublic/@inlinable has proven to improve performance, library authors 
will just start putting them anywhere as there's no downside besides making the 
code harder to read.

What is the downside of bringing the attributes and the compiler mode at the 
same time. Am I massively underestimating the amount of work required for such 
mode?


> I do hope that this attribute is not abused in the manner in which you 
> describe, but I’m not sure the potential for abuse is reason enough to not 
> run the proposal — people are already using the underscored attribute today, 
> risking source breakage and bugs due to insufficient test coverage in the 
> future.

> 
>> C(++) as described in the proposal and Haskell 
>> (https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE 
>> myFunction #-} (quoting the docs) causes exactly two things to happens.
>> 
>>  • The function's (exact) definition is included in the interface file 
>> for the module.
>>  • The function will be specialised at use sites -- even across modules.
>> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
>> function than any other.
> 
> Note that Swift’s compiler is the same — @inlinable does not influence 
> optimizer decisions to inline or not.

Cool, that's what I suspected. Good to know that the Swift & GHC attributes are 
the same and even the name is :).
So we just need -fspecialise-aggressively 邏.


> Also currently the proposal is implemented by binary serialization of the SIL 
> IR, but nothing in it precludes serializing inlinable function bodies as 
> source code in the future — in fact we are likely to go in that direction if 
> we implement the proposed textual ‘stable’ module format.

Cool. Just to be sure I understand you correctly: Assuming your proposal gets 
implemented as proposed, a function that does _not_ have the @inlinable 
attribute it won't be specialised across modules, ever. Correct?


-- Johannes

> 
> Slava
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 21, 2017, at 12:42 PM, Paul Cantrell  wrote:
> 
> 1. Presumably the portions of A inlined into B and C remain sensitive to the 
> version-specific memory layout of A? Or will ABI stability mean that the 
> compiler can magically rearrange memory offsets in already-compiled code when 
> the layout changes? (Apologies if this is a too-obvious question; this part 
> of Swift is all a mystery to me.)

There is not really a notion of memory layout at the level of an entire module. 
For structs, classes and enums, you pretty much have the same concerns with 
both inlinable and non-inlinable functions — if the framework author can change 
the stored property layout of a struct or class (or adds a case to an enum), 
code that manipulates these data types must not make any compile-time 
assumptions that might be invalidated at runtime with a newer version of the 
framework.

This is basically what the upcoming @fixedContents proposal for structs is 
about — giving framework authors a way to trade future flexibility for 
performance by allowing the compiler to make assumptions about the layout of a 
struct as it is written at compile-time. The @exhaustive proposal for enums has 
a similar implementation angle, but is of course more interesting because it 
affects the source language as well, with switch statements.

We don’t plan on any kind of resilience opt-out for classes — already in 
shipping Swift compilers, accesses to stored properties of classes use accessor 
methods and not direct access across module boundaries.

> 2. Is there some class of statically identifiable breaking changes that the 
> compiler does (or should) detect to flag incompatible inlined code? e.g. some 
> version of A inlined into B references A.foo, then A.foo is deleted in a 
> later version of A, so mixing older B with newer A in a project gives a 
> compile- or link-time error?

This is what an “ABI differ” tool would achieve, but like I said it has not yet 
been designed.

> 3. Does this need some sort of poison pill feature for other sorts of 
> breaking changes that are not statically detectable? e.g. invariants of a 
> data structure in A change in release 2.0, so the author of A says “it is an 
> error to include A ≥2.0 in any project that inlined any of my code from a 
> version <2.0.” Is this what you were getting at with the mention of 
> @inlinable(2.0) in the proposal? Sounded like that part was about something 
> else, but I didn’t really grasp it tbh.

This is an interesting point and I think it is outside of the scope of these 
proposals. If the ABI of a library changes in an incompatible manner and 
previous binaries are no longer compatible with it, you should think of it as 
shipping a *new* library, either by changing it’s name or bumping the major 
version number, so that the dynamic linker prevents the client binary from 
being run in the first place.

> Yes, frameworks+app built simultaneously are clearly the more common case. 
> Though Carthage seems to be champing at the bit to create this problem, since 
> it added a feature to download prebuilt binaries long before ABI stability! I 
> can easily imagining this feature spreading via word of mouth as a “secret go 
> faster switch,” and causing no end of problems in the wild.

Perhaps, but I still think it is strictly better to formalize the feature 
through a proposal and document the pitfalls carefully — the underscored 
attribute is already spreading through word of mouth and in the absence of 
official documentation the potential for abuse is greater.

> It might be safer — and better match the understanding of the typical user — 
> to have @inlinable assume by default that an inlined version of any given 
> method is only valid only for the specific version of the module it was 
> inlined from. The compiler would by default flag any version mixing as an 
> error, and require an explicit statement of compatibility intent for each 
> piece of inlinable code to opt in to the danger zone of mixed versions.

How would this be implemented?

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 21, 2017, at 11:05 AM, Greg Titus via swift-evolution 
>  wrote:
> 
> I come from a perspective similar to Johannes, in that: for my work we are 
> interested in the performance improvements of cross-module optimization and 
> specialization but we regularly rebuild frameworks along with apps and 
> explicitly don’t need ABI versioning. Unlike him, I’m not that concerned with 
> littering attributes for inlinability around, but for our purposes the 
> original proposed spelling of @inlinable/@abiPublic or even better, Tony’s 
> proposed public(inlinable) makes for easier understanding when reading the 
> code than Chris’s proposed @available() extensions, which semantically leans 
> much more heavily on the ABI versioning concept that we won’t otherwise need.

Yeah, the main downside I can think of with Chris’s approach is that for 
developers publishing source-only packages, version number ranges are probably 
overkill. I believe Jordan had a similar objection at some point in our 
internal discussions. However, treating @inlinable as shorthand for 
@available(inlinable) might be sufficient.


> 
> And the Tony-style spelling of @abiPublic should _clearly_ be 
> “internal(external)” for its amazingly oxymoronic yet accurate spelling.

If oxymoronic spelling discourages abuse of these features, I’m all for it ;-)

Slava

> 
>   — Greg
> 
>> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>>>  wrote:
>>> 
>>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>>> now and runs through January 5, 2018.
>>> 
>>> The proposal is available here:
>>> 
>>> 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
>>> 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?
>> 
>> I'm working on a performance sensitive library and we're sometimes bitten 
>> quite hard by not being able to cross-module inline & specialise. Therefore, 
>> it's thrilling to see that you're working in this area.
>> 
>> However, I have to admit that I believe this language feature will most 
>> likely be grossly abused. The library I'm working on will presumably never 
>> have stable ABI as you'd naturally build it with your application. However 
>> we also don't want to miss on the cross-module optimisation & specialisation 
>> and I suspect there are quite a few (mostly open-source) libraries in the 
>> same space. I'm pretty sure everybody would just end up littering their code 
>> with @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner 
>> proposed) without actually meaning that.
>> 
>> Summing up: I think this feature is crucial but shouldn't come without a 
>> compiler "where all declarations become implicitly @inlinable, and all 
>> private and internal declarations become @abiPublic". I really don't want to 
>> litter the code with attributes that aren't what I mean. (basically `swift 
>> build --global-resilience-domain`) Having this compiler mode also makes 
>> these attributes IMHO really niche and therefore I can only sympathise 
>> with's Chris' sentiment to not litter the global attribute namespace.
>> 
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> see above.
>> 
>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> to back up the 'swift' claim, cross-module inlining & specialisation is 
>> absolutely necessary. However this should also be achievable with a 'I don't 
>> need a stable ABI for this product' mode in the compiler :).
>> 
>> 
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>> 
>> C(++) as described in the proposal and Haskell 
>> (https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE 
>> myFunction #-} (quoting the docs) causes exactly two things to happens.
>> 
>>  

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

[Slava Pestov via swift-evolution]

Hi Johannes,

Thanks for reviewing this proposal!

> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>  wrote:

> The library I'm working on will presumably never have stable ABI as you'd 
> naturally build it with your application. However we also don't want to miss 
> on the cross-module optimisation & specialisation and I suspect there are 
> quite a few (mostly open-source) libraries in the same space. I'm pretty sure 
> everybody would just end up littering their code with @abiPublic/@inlinable 
> (or the @available(...) syntax Chris Lattner proposed) without actually 
> meaning that.
> 
> Summing up: I think this feature is crucial but shouldn't come without a 
> compiler "where all declarations become implicitly @inlinable, and all 
> private and internal declarations become @abiPublic". I really don't want to 
> litter the code with attributes that aren't what I mean. (basically `swift 
> build --global-resilience-domain`) Having this compiler mode also makes these 
> attributes IMHO really niche and therefore I can only sympathise with's 
> Chris' sentiment to not litter the global attribute namespace.

I agree that a ‘completely non-resilient’ compiler mode would be great when 
building libraries that are always shipped together, and I hope Swift gains 
such a feature one day, possibly built on top of the very infrastructure used 
to implement this proposal!

However, the goal of this proposal is to formalize some language features that 
already exist and are used by the standard library. Clearly making everything 
fragile is a non-starter for the standard library in an ABI-stable world.

I do hope that this attribute is not abused in the manner in which you 
describe, but I’m not sure the potential for abuse is reason enough to not run 
the proposal — people are already using the underscored attribute today, 
risking source breakage and bugs due to insufficient test coverage in the 
future.

> C(++) as described in the proposal and Haskell 
> (https://wiki.haskell.org/Inlining_and_Specialisation 
> ), where {-# INLINABLE 
> myFunction #-} (quoting the docs) causes exactly two things to happens.
> 
>   • The function's (exact) definition is included in the interface file 
> for the module.
>   • The function will be specialised at use sites -- even across modules.
> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
> function than any other.

Note that Swift’s compiler is the same — @inlinable does not influence 
optimizer decisions to inline or not.

Also currently the proposal is implemented by binary serialization of the SIL 
IR, but nothing in it precludes serializing inlinable function bodies as source 
code in the future — in fact we are likely to go in that direction if we 
implement the proposed textual ‘stable’ module format.

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

Thanks for the answers, Slava. More inline below.

> On Dec 21, 2017, at 12:30 AM, Slava Pestov  wrote:
> 
> Hi Paul,
> 
> Thanks for reviewing the proposal!
> 
>> On Dec 20, 2017, at 9:21 PM, Paul Cantrell > > wrote:
>> 
>> A concern: how would a library author reason about, and check for bugs in, 
>> the combinatorial explosion of old and new implementations that could exist 
>> simultaneously with this feature in use?
> 
> I don’t have a simple answer to this unfortunately, other than the author 
> being really careful, perhaps keeping around build artifacts that were 
> compiled against older versions of the library and testing those.
> 
>> That last paragraph gives a relatively trivial example, but the implications 
>> are daunting! If I understand correctly, anything in a library that uses any 
>> @inlinable or @abiPublic code must be prepared to deal with every possible 
>> combination of every past published implementation of that code. And that 
>> “every possible combination” is not per function, but per…call site?
>> 
>> Suppose we have this:
>> 
>> // Module A
>> 
>> @inlineable func bar() { ... }
>> 
>> // Module B
>> 
>> @inlineable func foo() {
>> if whatever {
>> bar(0)  // compiler decides to inline this...
>> } else {
>> bar(1)  // ...but not this, for whatever reason
>> }
>> }
>> 
>> // Module C
>> 
>> func baz() {
>> foo()
>> }
>> 
>> …and suppose B was compiled against A v1.0 but C was compiled against A 
>> v2.0. Then, if I’m following, it’s possible for bar(0) to use the 1.0 
>> implementation but bar(1) to use the 2.0 impl. Do I have that right? It 
>> seems to be what the hash value example is getting at.
> 
> That is correct. Another example is if module A publishes an inlinable 
> function, and module B and C depend on A, but B and C were compiled with 
> different versions of A. Then a fourth module D that depends on B and C might 
> see two different published versions of this function.

I am … horrified and intrigued! I suppose C++ headers have always had exactly 
the same problems, but never having been the maintainer of a C++ library, I 
never had to worry about it.

More follow-up “huh” questions:

1. Presumably the portions of A inlined into B and C remain sensitive to the 
version-specific memory layout of A? Or will ABI stability mean that the 
compiler can magically rearrange memory offsets in already-compiled code when 
the layout changes? (Apologies if this is a too-obvious question; this part of 
Swift is all a mystery to me.)

2. Is there some class of statically identifiable breaking changes that the 
compiler does (or should) detect to flag incompatible inlined code? e.g. some 
version of A inlined into B references A.foo, then A.foo is deleted in a later 
version of A, so mixing older B with newer A in a project gives a compile- or 
link-time error?

3. Does this need some sort of poison pill feature for other sorts of breaking 
changes that are not statically detectable? e.g. invariants of a data structure 
in A change in release 2.0, so the author of A says “it is an error to include 
A ≥2.0 in any project that inlined any of my code from a version <2.0.” Is this 
what you were getting at with the mention of @inlinable(2.0) in the proposal? 
Sounded like that part was about something else, but I didn’t really grasp it 
tbh.

> 
>> Or is this not as dangerous as I’m imagining it to be?
> 
> It *is* pretty dangerous, which is why I hope this feature is used 
> judiciously by third-party binary frameworks. With source frameworks that are 
> built together with an app and always recompiled, this is less of a concern.

Yes, frameworks+app built simultaneously are clearly the more common case. 
Though Carthage seems to be champing at the bit to create this problem, since 
it added a feature to download prebuilt binaries long before ABI stability! I 
can easily imagining this feature spreading via word of mouth as a “secret go 
faster switch,” and causing no end of problems in the wild.

Per this and my questions above, a proposal:

It might be safer — and better match the understanding of the typical user — to 
have @inlinable assume by default that an inlined version of any given method 
is only valid only for the specific version of the module it was inlined from. 
The compiler would by default flag any version mixing as an error, and require 
an explicit statement of compatibility intent for each piece of inlinable code 
to opt in to the danger zone of mixed versions.

Then inlinable code could opt in by specifying some sort of past and future 
compatibility contract, e.g. “inline-compatible with version 2.x of this 
module,” perhaps using syntax along the lines of the @available stuff Chris 
proposed elsewhere in this thread. IOW, my #3 just above would be necessary for 
the compiler to allow any version 

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

[Kelvin Ma via swift-evolution]

On Thu, Dec 21, 2017 at 12:26 AM, Slava Pestov  wrote:

> Thanks for the review, Kelvin.
>
> On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> it makes sense to have @abiPublic on private and fileprivate declarations
> too and i hope this gets added, because private and fileprivate are tools
> for code organization and maintenance,, the compiler with wmo doesn’t care
> about private vs internal. but @abiPublic private is bound to cause
> confusion and it just reads funny.
>
>
> From an implementation standpoint, it would be a simple change to allow
> @abiPublic on private and fileprivate declarations. However, I think that
> introduce some confusion. Recall that the mangling of private symbols
> includes the source file name. This would now be part of your framework’s
> ABI. If you moved the @abiPublic function to another source file, or rename
> the source file, you will break ABI.
>
> Another approach would be to change the mangling so that @abiPublic
> private symbols are mangled like internal symbols, with a module name and
> no source file name. This makes for a simpler ABI. However this also has a
> downside, because now if you define two @abiPublic private functions in
> different files that have the same mangling, you will get a linker error
> and not a nice compiler diagnostic.
>
> Note that nothing in this proposal precludes @abiPublic from being applied
> to private and fileprivate symbols though. If we figure out a nice solution
> to the above problems, we could generalize @abiPublic without any issues.
>
> Slava
>
>
i understand that but i also feel like that’s a completely solvable problem
if someone put in some effort to look into it. right now i think
fileprivate is the only problematic keyword with this since i think
changing the name of a private type makes a lot more sense that it would
break abi than renaming a file would. but it’s also the least used so
that’s a plus.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Titus via swift-evolution]

I come from a perspective similar to Johannes, in that: for my work we are 
interested in the performance improvements of cross-module optimization and 
specialization but we regularly rebuild frameworks along with apps and 
explicitly don’t need ABI versioning. Unlike him, I’m not that concerned with 
littering attributes for inlinability around, but for our purposes the original 
proposed spelling of @inlinable/@abiPublic or even better, Tony’s proposed 
public(inlinable) makes for easier understanding when reading the code than 
Chris’s proposed @available() extensions, which semantically leans much more 
heavily on the ABI versioning concept that we won’t otherwise need.

And the Tony-style spelling of @abiPublic should _clearly_ be 
“internal(external)” for its amazingly oxymoronic yet accurate spelling.

— Greg

> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>  wrote:
> 
> 
>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>>  wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> 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
>> 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?
> 
> I'm working on a performance sensitive library and we're sometimes bitten 
> quite hard by not being able to cross-module inline & specialise. Therefore, 
> it's thrilling to see that you're working in this area.
> 
> However, I have to admit that I believe this language feature will most 
> likely be grossly abused. The library I'm working on will presumably never 
> have stable ABI as you'd naturally build it with your application. However we 
> also don't want to miss on the cross-module optimisation & specialisation and 
> I suspect there are quite a few (mostly open-source) libraries in the same 
> space. I'm pretty sure everybody would just end up littering their code with 
> @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) 
> without actually meaning that.
> 
> Summing up: I think this feature is crucial but shouldn't come without a 
> compiler "where all declarations become implicitly @inlinable, and all 
> private and internal declarations become @abiPublic". I really don't want to 
> litter the code with attributes that aren't what I mean. (basically `swift 
> build --global-resilience-domain`) Having this compiler mode also makes these 
> attributes IMHO really niche and therefore I can only sympathise with's 
> Chris' sentiment to not litter the global attribute namespace.
> 
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> see above.
> 
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> to back up the 'swift' claim, cross-module inlining & specialisation is 
> absolutely necessary. However this should also be achievable with a 'I don't 
> need a stable ABI for this product' mode in the compiler :).
> 
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> C(++) as described in the proposal and Haskell 
> (https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE 
> myFunction #-} (quoting the docs) causes exactly two things to happens.
> 
>   • The function's (exact) definition is included in the interface file 
> for the module.
>   • The function will be specialised at use sites -- even across modules.
> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
> function than any other.
> 
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> read the proposal (and believe to understand it).
> 
> -- Johannes
> 
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 

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

[Johannes Weiß via swift-evolution]

> On 21 Dec 2017, at 4:06 pm, Johannes Weiß via swift-evolution 
>  wrote:
> 
>> 
>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>>  wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> 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
>> 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?
> 
> I'm working on a performance sensitive library and we're sometimes bitten 
> quite hard by not being able to cross-module inline & specialise. Therefore, 
> it's thrilling to see that you're working in this area.
> 
> However, I have to admit that I believe this language feature will most 
> likely be grossly abused. The library I'm working on will presumably never 
> have stable ABI as you'd naturally build it with your application. However we 
> also don't want to miss on the cross-module optimisation & specialisation and 
> I suspect there are quite a few (mostly open-source) libraries in the same 
> space. I'm pretty sure everybody would just end up littering their code with 
> @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) 
> without actually meaning that.
> 
> Summing up: I think this feature is crucial but shouldn't come without a 
> compiler "where all declarations become implicitly @inlinable, and all 
> private and internal declarations become @abiPublic". I really don't want to 
> litter the code with attributes that aren't what I mean. (basically `swift 
> build --global-resilience-domain`) Having this compiler mode also makes these 
> attributes IMHO really niche and therefore I can only sympathise with's 
> Chris' sentiment to not litter the global attribute namespace.
> 
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> see above.
> 
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> to back up the 'swift' claim, cross-module inlining & specialisation is 
> absolutely necessary. However this should also be achievable with a 'I don't 
> need a stable ABI for this product' mode in the compiler :).
> 
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> C(++) as described in the proposal and Haskell 
> (https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE 
> myFunction #-} (quoting the docs) causes exactly two things to happens.
> 
>   • The function's (exact) definition is included in the interface file 
> for the module.
>   • The function will be specialised at use sites -- even across modules.
> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
> function than any other.

forgot to mention GHC's -fspecialise-aggressively which is its way of saying, 
just specialise things across modules even without '{-# INLINABLE ... #-}' 
which is basically the compilation mode I'm asking for :).

> 
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> read the proposal (and believe to understand it).
> 
> -- Johannes
> 
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Johannes Weiß via swift-evolution]

> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE-0193 - Cross-module inlining and specialization" begins now 
> and runs through January 5, 2018.
> 
> The proposal is available here:
> 
> 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
> 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?

I'm working on a performance sensitive library and we're sometimes bitten quite 
hard by not being able to cross-module inline & specialise. Therefore, it's 
thrilling to see that you're working in this area.

However, I have to admit that I believe this language feature will most likely 
be grossly abused. The library I'm working on will presumably never have stable 
ABI as you'd naturally build it with your application. However we also don't 
want to miss on the cross-module optimisation & specialisation and I suspect 
there are quite a few (mostly open-source) libraries in the same space. I'm 
pretty sure everybody would just end up littering their code with 
@abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) 
without actually meaning that.

Summing up: I think this feature is crucial but shouldn't come without a 
compiler "where all declarations become implicitly @inlinable, and all private 
and internal declarations become @abiPublic". I really don't want to litter the 
code with attributes that aren't what I mean. (basically `swift build 
--global-resilience-domain`) Having this compiler mode also makes these 
attributes IMHO really niche and therefore I can only sympathise with's Chris' 
sentiment to not litter the global attribute namespace.


>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

see above.


>   • Does this proposal fit well with the feel and direction of Swift?

to back up the 'swift' claim, cross-module inlining & specialisation is 
absolutely necessary. However this should also be achievable with a 'I don't 
need a stable ABI for this product' mode in the compiler :).


>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

C(++) as described in the proposal and Haskell 
(https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE 
myFunction #-} (quoting the docs) causes exactly two things to happens.

• The function's (exact) definition is included in the interface file 
for the module.
• The function will be specialised at use sites -- even across modules.
Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
function than any other.


>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

read the proposal (and believe to understand it).

-- Johannes

> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 20, 2017, at 10:34 PM, Slava Pestov via swift-evolution 
>  wrote:
> 
>> Perhaps a diagnostic like this would cause problems if you started with an 
>> @inlinable function that called an @abiPublic function and then in a 
>> subsequent version of your module you modified the @inlinable function such 
>> that it no longer calls the @abiPublic function. You would still need to 
>> keep that @abiPublic function to support clients that had inlined the old 
>> version, right?
> 
> This is correct; you may well end up with newer versions of a library that 
> carry @abiPublic symbols only for compatibility reasons.

Perhaps an “unused symbol checker” could skip @abiPublic declarations that have 
been marked as deprecated or unavailable.

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 20, 2017, at 10:17 PM, Adam Kemp via swift-evolution 
>  wrote:
> 
> Should there be some kind of diagnostic if you have an @abiPublic definition 
> that is never referenced by any @inlinable function? I can imagine that there 
> might be tools to check that a new build of a module doesn’t break binary 
> compatibility by verifying that you didn’t remove any @abiPublic symbols, but 
> what if you never meant to and never needed to export that symbol in the 
> first place? How do we prevent that from happening?

>From a technical standpoint it would be possible to implement such a 
>diagnostic, with the caveat that it would probably only work in whole module 
>optimization mode. However, you’re right that there’s a complication here:

> Perhaps a diagnostic like this would cause problems if you started with an 
> @inlinable function that called an @abiPublic function and then in a 
> subsequent version of your module you modified the @inlinable function such 
> that it no longer calls the @abiPublic function. You would still need to keep 
> that @abiPublic function to support clients that had inlined the old version, 
> right?

This is correct; you may well end up with newer versions of a library that 
carry @abiPublic symbols only for compatibility reasons.

> Maybe this could be built into the hypothetical binary compatibility checker. 
> If there is no previous version or if the previous version didn’t have the 
> symbol and it’s never referenced then it’s an error. Would that work? Am I 
> overthinking this?

Yes, that would certainly be possible. We’ve discussed having an “ABI differ” 
tool as something we would really like to have, but so far no concrete design 
has been proposed. I expect this discussion will take on a greater urgency once 
we get close to shipping the second version of an “ABI stable” standard 
library. It’s obviously not needed the first time around.

Slava

> 
> On Dec 20, 2017, at 4:19 PM, Ted Kremenek via swift-evolution 
> > wrote:
> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> 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 
>> 
>> 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?
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

Hi Brent,

> On Dec 20, 2017, at 9:35 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> I concur. If we don't care about its ungainly size, the blindingly obvious 
> solution would be `@inlineCallable`. Another solution might be to declare the 
> symbol with a combination like `@hidden public`, which I assume is a closer 
> representation of how this feature is actually implemented.

@hidden public seems more confusing to me, because the symbol is not public to 
name lookup. @abiPublic has no effect on source compatibility, only binary 
compatibility.

> 
> (Incidentally, the proposal doesn't mention `open`; I suspect that it 
> probably should.)

I can revise the proposal to add a brief mention of ‘open’ if you’d like. As 
you may have guessed already there is no distinction between ‘open’ and 
‘public’ here.

Slava___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

Hi Paul,

Thanks for reviewing the proposal!

> On Dec 20, 2017, at 9:21 PM, Paul Cantrell  wrote:
> 
> A concern: how would a library author reason about, and check for bugs in, 
> the combinatorial explosion of old and new implementations that could exist 
> simultaneously with this feature in use?

I don’t have a simple answer to this unfortunately, other than the author being 
really careful, perhaps keeping around build artifacts that were compiled 
against older versions of the library and testing those.

> That last paragraph gives a relatively trivial example, but the implications 
> are daunting! If I understand correctly, anything in a library that uses any 
> @inlinable or @abiPublic code must be prepared to deal with every possible 
> combination of every past published implementation of that code. And that 
> “every possible combination” is not per function, but per…call site?
> 
> Suppose we have this:
> 
> // Module A
> 
> @inlineable func bar() { ... }
> 
> // Module B
> 
> @inlineable func foo() {
> if whatever {
> bar(0)  // compiler decides to inline this...
> } else {
> bar(1)  // ...but not this, for whatever reason
> }
> }
> 
> // Module C
> 
> func baz() {
> foo()
> }
> 
> …and suppose B was compiled against A v1.0 but C was compiled against A v2.0. 
> Then, if I’m following, it’s possible for bar(0) to use the 1.0 
> implementation but bar(1) to use the 2.0 impl. Do I have that right? It seems 
> to be what the hash value example is getting at.

That is correct. Another example is if module A publishes an inlinable 
function, and module B and C depend on A, but B and C were compiled with 
different versions of A. Then a fourth module D that depends on B and C might 
see two different published versions of this function.

> Or is this not as dangerous as I’m imagining it to be?

It *is* pretty dangerous, which is why I hope this feature is used judiciously 
by third-party binary frameworks. With source frameworks that are built 
together with an app and always recompiled, this is less of a concern.

Also we are using this feature extensively in the standard library, so as the 
standard library evolves we will learn and develop best practices, hopefully 
without too many hiccups :)

Slava

> 
> Cheers, P
> 
> 
>> On Dec 20, 2017, at 6:19 PM, Ted Kremenek via swift-evolution 
>> > wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> 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 
>> 
>> 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?
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

Thanks for the review, Kelvin.

> On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> it makes sense to have @abiPublic on private and fileprivate declarations too 
> and i hope this gets added, because private and fileprivate are tools for 
> code organization and maintenance,, the compiler with wmo doesn’t care about 
> private vs internal. but @abiPublic private is bound to cause confusion and 
> it just reads funny. 

>From an implementation standpoint, it would be a simple change to allow 
>@abiPublic on private and fileprivate declarations. However, I think that 
>introduce some confusion. Recall that the mangling of private symbols includes 
>the source file name. This would now be part of your framework’s ABI. If you 
>moved the @abiPublic function to another source file, or rename the source 
>file, you will break ABI.

Another approach would be to change the mangling so that @abiPublic private 
symbols are mangled like internal symbols, with a module name and no source 
file name. This makes for a simpler ABI. However this also has a downside, 
because now if you define two @abiPublic private functions in different files 
that have the same mangling, you will get a linker error and not a nice 
compiler diagnostic.

Note that nothing in this proposal precludes @abiPublic from being applied to 
private and fileprivate symbols though. If we figure out a nice solution to the 
above problems, we could generalize @abiPublic without any issues.

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adam Kemp via swift-evolution]

Should there be some kind of diagnostic if you have an @abiPublic definition 
that is never referenced by any @inlinable function? I can imagine that there 
might be tools to check that a new build of a module doesn’t break binary 
compatibility by verifying that you didn’t remove any @abiPublic symbols, but 
what if you never meant to and never needed to export that symbol in the first 
place? How do we prevent that from happening?

Perhaps a diagnostic like this would cause problems if you started with an 
@inlinable function that called an @abiPublic function and then in a subsequent 
version of your module you modified the @inlinable function such that it no 
longer calls the @abiPublic function. You would still need to keep that 
@abiPublic function to support clients that had inlined the old version, right?

Maybe this could be built into the hypothetical binary compatibility checker. 
If there is no previous version or if the previous version didn’t have the 
symbol and it’s never referenced then it’s an error. Would that work? Am I 
overthinking this?

> On Dec 20, 2017, at 4:19 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE-0193 - Cross-module inlining and specialization" begins now 
> and runs through January 5, 2018.
> 
> The proposal is available here:
> 
> 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
> 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?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Dec 20, 2017, at 4:19 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE-0193 - Cross-module inlining and specialization" begins now 
> and runs through January 5, 2018.
> 
> The proposal is available here:
> 
> 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
> 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?
> 
+1
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
yes
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
yes, I’d suggest a name like @abiExposed.
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
C++ but on briefly. 
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
read proposal. used _ attribute in the past but never really needed it. 
> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On Dec 20, 2017, at 7:01 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> My one bikeshedding issue here is the name @abiPublic, which smells too much 
> like fileprivate in my subjective opinion. A more concrete objection here is 
> the very much non-ideal juxtaposition of two different access modifier terms 
> in the "@abiPublic internal" spelling. It would seem to me that "@abi" would 
> suffice instead. Indeed, the fact that it's an "interface" implies a certain 
> level of visibility, which in my view is more precise than coopting the term 
> "public"--that term in turn has an established meaning in Swift that, by 
> construction, an "@abiPublic internal" method does not fulfill.

I concur. If we don't care about its ungainly size, the blindingly obvious 
solution would be `@inlineCallable`. Another solution might be to declare the 
symbol with a combination like `@hidden public`, which I assume is a closer 
representation of how this feature is actually implemented.

(Incidentally, the proposal doesn't mention `open`; I suspect that it probably 
should.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

This seems like a problem worth solving — or rather worth making the solution 
public, since this is already in use as an undocumented feature!

A concern: how would a library author reason about, and check for bugs in, the 
combinatorial explosion of old and new implementations that could exist 
simultaneously with this feature in use?

The proposal touches on this in the “Effect on API resilience” section:

> Any changes to the body of a declaration annotated as @inlinable should be 
> considered very carefully. As a general guideline, we feel that @inlinable 
> makes the most sense with "obviously correct" algorithms which manipulate 
> other data types abstractly through protocols, so that any future changes to 
> an @inlinable declaration are optimizations that do not change observed 
> behavior.
> 
> Also, an @inlinable function implementation must be prepared to interact with 
> multiple versions of the same function linked into a single binary. For 
> example, if a hashing function is @inlinable, the hash algorithm must not be 
> changed to avoid introducing inconsistency.


That last paragraph gives a relatively trivial example, but the implications 
are daunting! If I understand correctly, anything in a library that uses any 
@inlinable or @abiPublic code must be prepared to deal with every possible 
combination of every past published implementation of that code. And that 
“every possible combination” is not per function, but per…call site?

Suppose we have this:

// Module A

@inlineable func bar() { ... }

// Module B

@inlineable func foo() {
if whatever {
bar(0)  // compiler decides to inline this...
} else {
bar(1)  // ...but not this, for whatever reason
}
}

// Module C

func baz() {
foo()
}

…and suppose B was compiled against A v1.0 but C was compiled against A v2.0. 
Then, if I’m following, it’s possible for bar(0) to use the 1.0 implementation 
but bar(1) to use the 2.0 impl. Do I have that right? It seems to be what the 
hash value example is getting at.

The potential for undetected bugs seems enormous. I wonder if there’s a need 
for extra assistance for library authors, e.g.:

• A tool that allows one to take binaries for multiple versions of a lib with 
inlinables, and repeatedly runs a test suite using a randomly selected version 
of each inlinable func every time it’s used

• Static sanity checks (but what would they be?)

• Strict module version match conditions on @inlineable (but then dependency 
hell takes up residence in the compiler?)

• Bail on compilation and JIT everything (ha)

Or is this not as dangerous as I’m imagining it to be?

Cheers, P


> On Dec 20, 2017, at 6:19 PM, Ted Kremenek via swift-evolution 
>  wrote:
> 
> The review of "SE-0193 - Cross-module inlining and specialization" begins now 
> and runs through January 5, 2018.
> 
> The proposal is available here:
> 
> 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
> 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?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Kelvin Ma via swift-evolution]

glad to see this finally moving forward!

On Wed, Dec 20, 2017 at 6:19 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
> 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
>
> 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?
>
> this is a feature i have been waiting for for a long time so needless to
say i strongly support this proposal. one comment is that @abiPublic is a
kind of awkward thing to have around, not because of how it’s spelled but
because i think access control and abi visibility are orthogonal concepts
and i’m not a fan of overloading access control terms for abi concepts. it
makes sense to have @abiPublic on private and fileprivate declarations too
and i hope this gets added, because private and fileprivate are tools for
code organization and maintenance,, the compiler with wmo doesn’t care
about private vs internal. but @abiPublic private is bound to cause
confusion and it just reads funny.


>
>-
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>
> Yes. this issue (along with generic specialization which is really
rendered mostly irrelevant by inlining) is the main technical barrier
preventing a swift core library ecosystem from taking root. formalizing
this feature will allow library authors like me to ship and use modules for
low level tasks, whereas previously the workaround was to copy and paste handy
.swift files  containing
implementations of common data structures and algorithms. ultimately this
will help maintainability, code reuse, and general code base cleanliness.


>
>-
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>
> i don’t see why it wouldn’t. the proposal seems overly conservative and
leans a bit too far towards maximum resilience vs maximum optimization but
that’s fine.

>
>-
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>
> this is a big step up from the c++ thing where you would just distribute
giant “header-only” libraries so

>
>-
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> i read the whole thing,, and i’ve been following this discussion for a
while

>
>-
>
> Thanks,
> Ted Kremenek
> Review Manager
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

Hi Tony,

Thanks for the review!

> On Dec 20, 2017, at 8:09 PM, Tony Allevato via swift-evolution 
>  wrote:
> 
> A related question (with some background): My assumption is that conditional 
> compilation directives (e.g., #if DEBUG) are resolved *before* an @inlinable 
> function is serialized to the module. Is that correct?

That is correct. Conditional compilation directives are always resolved in the 
context of the defining module.

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tony Allevato via swift-evolution]

On Wed, Dec 20, 2017 at 4:19 PM Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
>
> 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
>
> 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?
>
> +1. I've worked on a performance-sensitive codebase (Swift protocol
buffers) where being able to optimize across module boundaries (using
documented features!) would be a huge win.


>-
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>
> Yes.

>
>-
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>
> Yes, aside from the inevitable name bikeshedding. :)

I share Xiaodi's view that "@abiPublic" feels like it's coöpting "public"
in an odd way, especially when that attribute specifically only applies to
internal decls. I could get behind "@abi", but that doesn't quite feel like
"enough". "@abiVisible" comes to mind as a possibility—the declaration
isn't "public", but it's "visible" in the ABI.

A related question (with some background): My assumption is that
conditional compilation directives (e.g., #if DEBUG) are resolved *before*
an @inlinable function is serialized to the module. Is that correct? In
other words, if I have this:

-
// Logger
@inlinable func log(_ msg: String) {
#if DEBUG
  print(msg)
#endif
}

// Client
import Logger
log("hello")
-

Then when Logger is compiled, the call to print() is *not serialized at
all* if DEBUG is undefined, right? (As opposed to serializing the
conditional and the body and then using the value of DEBUG in *Client's*
compilation to decide whether the code is present when inlined.)

The reason I ask is because I've been looking at how to tackle logging in
Swift—specifically the ability to have debug logging statements completely
stripped (including the strings passed to them) in release binaries. This
can be achieved today if the logging function is in the same module as the
caller and you do an optimized build (and you trust the optimizer to do
this reliably); the entire function call and its strings are dropped.

But if Logger is a separate module, this is no longer possible. @inlinable
is one of the ways that I thought this problem could be resolved, but only
if the conditionals are also serialized and reapplied against the client's
-D flags, and only if the attribute is a *guarantee* from the compiler and
not just a *suggestion* to it.

My hunch is that this is out of scope for this particular proposal (and
would be a "side effect" at best rather than a "feature" even if it did
work), but I'd love to hear your thoughts on that!


>-
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>
> Just C++, as described in the proposal. It's unfortunate that C++'s
separate header/source structure makes this more elegant in a sense than
the Swift solution using attributes, by virtue of just deciding where you
place the code. That being said, I can't think of a more elegant approach.


>
>-
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Followed earlier discussions and read the proposal.



>
>-
>
> Thanks,
> Ted Kremenek
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

Hi Nevin,

Thanks for taking the time to review the proposal!

> On Dec 20, 2017, at 7:08 PM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Alternatively, since the “@abiPublic” attribute allows objects to be used by 
> inlined code, why not spell it “@inlinable”?
> 

Because both @abiPublic and @inlinable can be applied to functions, and we 
really do need to distinguish the two cases — they’re definitely not the same:

private func pf() {}

@abiPublic func af() {
  pf() // OK — we can reference a private function here
  // framework author can change the body of af() and clients see the new body
}

@inlinable public func if() {
  pf() // error!

  af() // OK

  // changes made here don’t necessarily get picked up by clients until 
recompiled
}

Slava___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

Hi Xiaodi,

Thanks for taking the time to look over the proposal.

> On Dec 20, 2017, at 7:01 PM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, with a caveat. It seems a little unfortunate that @inline(never) is 
> spelled so differently from @inlinable. Probably too late to rename the 
> former @noninlinable though. It'd be lovely though.

So @inline(never) is not the opposite of @inlinable, it is something completely 
different:

- @inline(never) impacts the optimizer’s behavior inside the module, where as 
@inlinable has no effect on callees inside a module.
- You can in fact define a function that is @inline(never) and @inlinable. This 
would allow the function to be specialized or otherwise emitted inside a client 
module, but neither the specialization nor the original function would ever be 
inlined.

I’d like the swift-evolution community to discuss @inline(never) and 
@inline(__always) at some point, but I think they’re sufficiently unrelated to 
this proposal that we should probably not try to fit them in.

Slava___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Nevin Brackett-Rozinsky via swift-evolution]

On Wed, Dec 20, 2017 at 10:01 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:
>
> I have been doing the unkosher thing of using these underscored attributes
> and would very much like to see these formalized.
>
> My one bikeshedding issue here is the name @abiPublic, which smells too
> much like fileprivate in my subjective opinion. A more concrete objection
> here is the very much non-ideal juxtaposition of two different access
> modifier terms in the "@abiPublic internal" spelling. It would seem to me
> that "@abi" would suffice instead. Indeed, the fact that it's an
> "interface" implies a certain level of visibility, which in my view is more
> precise than coopting the term "public"--that term in turn has an
> established meaning in Swift that, by construction, an "@abiPublic
> internal" method does not fulfill.
>

Alternatively, since the “@abiPublic” attribute allows objects to be used
by inlined code, why not spell it “@inlinable”?

Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Wed, Dec 20, 2017 at 18:19 Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:

> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
>
> 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
>
> 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?
>
>
I have been doing the unkosher thing of using these underscored attributes
and would very much like to see these formalized.

My one bikeshedding issue here is the name @abiPublic, which smells too
much like fileprivate in my subjective opinion. A more concrete objection
here is the very much non-ideal juxtaposition of two different access
modifier terms in the "@abiPublic internal" spelling. It would seem to me
that "@abi" would suffice instead. Indeed, the fact that it's an
"interface" implies a certain level of visibility, which in my view is more
precise than coopting the term "public"--that term in turn has an
established meaning in Swift that, by construction, an "@abiPublic
internal" method does not fulfill.


>- Is the problem being addressed significant enough to warrant a
>change to Swift?
>
>
Yes, we need this.


>- Does this proposal fit well with the feel and direction of Swift?
>
>
Yes, with a caveat. It seems a little unfortunate that @inline(never) is
spelled so differently from @inlinable. Probably too late to rename the
former @noninlinable though. It'd be lovely though.


>- If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
>
>
Not really, no.


>- How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
>
I have used the underscored feature already, and I have read the document.

Thanks,
> Ted Kremenek
> Review Manager
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Ted Kremenek via swift-evolution]

The review of "SE-0193 - Cross-module inlining and specialization" begins now 
and runs through January 5, 2018.
The proposal is available here:
> 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
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?

Thanks,
Ted Kremenek
Review Manager

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution