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

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).

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

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

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

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

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

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 >

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

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

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

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

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

> 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

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

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

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

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.

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

> 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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

> 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

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

> 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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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:

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

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

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

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

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

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

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

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

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

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

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

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