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] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

vv

On Sun, Dec 24, 2017 at 11:36 PM, Howard Lovatt 
wrote:

> I would say yes they are different for the example. Definitely something I
> miss is nesting types to given a seperate namespace.
>
> -- Howard.
>
> > On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > There was a proposal to allow protocols to be nested inside types at one
> point but it didn’t move forward.
> >
> > Basically, if the outer type is a non-generic class, struct or enum,
> there’s no conceptual difficulty at all.
> >
> > If the outer type is a generic type or another protocol, you have a
> problem where the inner protocol can reference generic parameters or
> associated types of the outer type. This would either have to be banned, or
> we would need to come up with coherent semantics for it:
> >
> > struct Generic {
> >  protocol P {
> >func f() -> T
> >  }
> > }
> >
> > struct Conforms : Generic.P {
> >  func f() -> Int { … } // Like this?
> > }
> >
> > let c = Conforms()
> > c is Generic.P // is this false? Ie, are Generic.P and
> Generic.P different protocols?
> >
> > Slava
> >
> >> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
> >>
> >> is there a reason why it’s not allowed to nest a protocol declaration
> inside another type?
> >> ___
> >> 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] namespacing protocols to other types

[Howard Lovatt via swift-evolution]

I would say yes they are different for the example. Definitely something I miss 
is nesting types to given a seperate namespace. 

-- Howard. 

> On 24 Dec 2017, at 9:56 pm, Slava Pestov via swift-evolution 
>  wrote:
> 
> There was a proposal to allow protocols to be nested inside types at one 
> point but it didn’t move forward.
> 
> Basically, if the outer type is a non-generic class, struct or enum, there’s 
> no conceptual difficulty at all.
> 
> If the outer type is a generic type or another protocol, you have a problem 
> where the inner protocol can reference generic parameters or associated types 
> of the outer type. This would either have to be banned, or we would need to 
> come up with coherent semantics for it:
> 
> struct Generic {
>  protocol P {
>func f() -> T
>  }
> }
> 
> struct Conforms : Generic.P {
>  func f() -> Int { … } // Like this?
> }
> 
> let c = Conforms()
> c is Generic.P // is this false? Ie, are Generic.P and 
> Generic.P different protocols?
> 
> Slava
> 
>> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution 
>>  wrote:
>> 
>> is there a reason why it’s not allowed to nest a protocol declaration inside 
>> another type?
>> ___
>> 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

[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] namespacing protocols to other types

[Slava Pestov via swift-evolution]

There was a proposal to allow protocols to be nested inside types at one point 
but it didn’t move forward.

Basically, if the outer type is a non-generic class, struct or enum, there’s no 
conceptual difficulty at all.

If the outer type is a generic type or another protocol, you have a problem 
where the inner protocol can reference generic parameters or associated types 
of the outer type. This would either have to be banned, or we would need to 
come up with coherent semantics for it:

struct Generic {
  protocol P {
func f() -> T
  }
}

struct Conforms : Generic.P {
  func f() -> Int { … } // Like this?
}

let c = Conforms()
c is Generic.P // is this false? Ie, are Generic.P and 
Generic.P different protocols?

Slava

> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution 
>  wrote:
> 
> is there a reason why it’s not allowed to nest a protocol declaration inside 
> another type?
> ___
> 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] namespacing protocols to other types

[Kelvin Ma via swift-evolution]

is there a reason why it’s not allowed to nest a protocol declaration
inside another type?
___
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 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