Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Oct 5, 2017, at 1:30 PM, Joe Groff wrote: >> On Oct 4, 2017, at 9:24 PM, Chris Lattner wrote: >> On Oct 4, 2017, at 9:44 AM, Joe Groff wrote: I disagree. The semantics being proposed perfectly overlap with the transitional plan for overlays (which matters for the next few years),

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 9:32 AM, Joe Groff wrote: > >>> >>> The suggestion to have this semantics was originally my fault, I believe, >>> and it arose from the observation that if we have 'inlinable' backed by a >>> symbol in the binary, then we'd also want the 'must be emitted by client' >>> a

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Hi all, Summarizing the thread so far, I see there were three main points of discussion: - The name itself, @inlinable, is causing some confusion. Chris suggested a more general name, like @fragile. A few other possible names were discussed. I don’t think we’ve decided on the best name yet so I

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:24 PM, Chris Lattner wrote: > > On Oct 4, 2017, at 9:44 AM, Joe Groff wrote: >>> I disagree. The semantics being proposed perfectly overlap with the >>> transitional plan for overlays (which matters for the next few years), but >>> they are the wrong default for anyth

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 1:17 PM, Michael Ilseman via swift-evolution > wrote: > > Another benefit of the always-emit-into-client-and-omit-from-libary-binary is > cross-call consistency. A function foo could change in a way such that *all* > calls using either the new or old version is fine, but

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Another benefit of the always-emit-into-client-and-omit-from-libary-binary is cross-call consistency. A function foo could change in a way such that *all* calls using either the new or old version is fine, but some interleaving of calls to new and old versions is invalid. Having to reason about

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 12:01 AM, Slava Pestov via swift-evolution > wrote: > > Oh right. @_specialize modifies the original entry point to do runtime > dispatch among the possible specializations. So the overhead comes from the > unnecessary checks. I guess ideally we would have two versions of

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 10:46 AM, Taylor Swift wrote: > > why is runtime dispatch even necessary? Why can’t the client just call the > specialized version directly? Runtime dispatch on the callee side keeps the exact set of specializations open to change, since it isn't ABI, and in theory shoul

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

why is runtime dispatch even necessary? Why can’t the client just call the specialized version directly? On Thu, Oct 5, 2017 at 2:01 AM, Slava Pestov wrote: > Oh right. @_specialize modifies the original entry point to do runtime > dispatch among the possible specializations. So the overhead com

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Hi Slava, What is the impact on debugging? Will we emit a non-inline version of the function into the client at Onone? Will it be impossible to call from a debugger with optimization enabled? I've been burned by this in C++. Ben > On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:15 PM, Chris Lattner wrote: > > >> On Oct 4, 2017, at 9:36 AM, Joe Groff > > wrote: >> > It wouldn't avoid the complexity, because we want the "non-ABI, > always-emit-into-client" behavior for the standard library. For the > soon-t

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Oh right. @_specialize modifies the original entry point to do runtime dispatch among the possible specializations. So the overhead comes from the unnecessary checks. I guess ideally we would have two versions of @_specialize, one adds the runtime dispatch whereas the other one just publishes st

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

See the thread from july over generic trig functions, where @_specialize() + @_inlineable had a small but consistent performance penalty relative to @_inlineable alone. On Thu, Oct 5, 2017 at 1:32 AM, Slava Pestov

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 11:04 PM, Taylor Swift wrote: > > > > On Oct 5, 2017, at 12:52 AM, Slava Pestov > wrote: > >> >> >>> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> i’m just tryna follow al

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 12:52 AM, Slava Pestov wrote: > > > >> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution >> wrote: >> >> i’m just tryna follow along here && this is probably a dumb question, but is >> it possible for a generic function to be emitted as a set of specialized

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:40 PM, Taylor Swift via swift-evolution > wrote: > > i’m just tryna follow along here && this is probably a dumb question, but is > it possible for a generic function to be emitted as a set of specialized > functions into the client, but not inlined everywhere? It can

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:40 PM, Taylor Swift wrote: > > > - It becomes an ABI compatibility liability that has to be preserved forever. > - It increases binary size for a function that's rarely used, and which is > often much larger as an outlined generic function than the simple operation > t

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Wed, Oct 4, 2017 at 11:44 AM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > > > On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > > > > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution < > swift-evolution@

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:24 PM, Chris Lattner via swift-evolution > wrote: > >> >> - It increases binary size for a function that's rarely used, and which is >> often much larger as an outlined generic function than the simple operation >> that can be inlined into client code. Inlining makes t

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Oct 4, 2017, at 9:44 AM, Joe Groff wrote: >> I disagree. The semantics being proposed perfectly overlap with the >> transitional plan for overlays (which matters for the next few years), but >> they are the wrong default for anything other than overlays and the wrong >> thing for long term

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:36 AM, Joe Groff wrote: > It wouldn't avoid the complexity, because we want the "non-ABI, always-emit-into-client" behavior for the standard library. For the soon-to-be-ABI-stable libraries where @inlinable even matters, such as the standard library

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 5:45 PM, Xiaodi Wu via swift-evolution < swift-evolution@swift.org> wrote: > This is unduly restrictive; @_versioned (despite being the wrong spelling) > is what we want here. To be callable from an inlinable function, internal > things need only be visible in terms of publi

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:46 AM, Joe Groff via swift-evolution > wrote: > > > > On Oct 3, 2017, at 10:03 PM, Chris Lattner wrote: > >> >>> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: >>> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> wrote: The major

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

How does @inlinable relate to the @_specialize attribute described in https://github.com/apple/swift/pull/6797 (original swift-evolution post about it: https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160314/001449.html)? Here's how I understand it: @_specialize emits the specialized

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:03 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: >> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> The major question I have is “why yet another attribute”. The thread about >>> exhaustive/ext

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: >> >> >> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution wrote: We have discussed adding a "versioned @inlinable" variant that preserves the pu

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:59 PM, Slava Pestov wrote: > > > >>> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: >>> >>> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > > We have

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

>> >> Anyway, for my use case mentioned earlier (shipping a release version of my >> app bundle), that doesn’t really matter. I’d just like a compiler switch >> that made the whole module not having an ABI, essentially making all all >> methods and types @inlinable and @_versioned, using the t

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 11:05 PM, Jonas B wrote: > > >> On 4 Oct 2017, at 14:33, Slava Pestov > > wrote: >> >> @_versioned makes a symbol visible externally without making it visible from >> the language. There is no requirement that a @_versioned thing is >> @inlinab

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On 4 Oct 2017, at 14:33, Slava Pestov wrote: > > @_versioned makes a symbol visible externally without making it visible from > the language. There is no requirement that a @_versioned thing is @inlinable. > It is used when you want to reference an internal function from an inlinable > func

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On 4 Oct 2017, at 07:16, Chris Lattner via swift-evolution > wrote: > > >> On Oct 3, 2017, at 10:11 PM, Slava Pestov > > wrote: >> However I’m still waiting for Dave or Jordan to chime in with the original justification for the ‘always emit into client’

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On 4 Oct 2017, at 07:11, Slava Pestov via swift-evolution > wrote: > > > >> On Oct 3, 2017, at 10:09 PM, Chris Lattner > > wrote: >> >> On Oct 3, 2017, at 9:59 PM, Slava Pestov > > wrote: > It wouldn't avoid the complexity, because

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:32 PM, Jonas B wrote: > > >> On 4 Oct 2017, at 13:36, Slava Pestov > > wrote: >> >>> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> Now I understand that this use-case is de

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On 4 Oct 2017, at 13:36, Slava Pestov wrote: > >> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> Now I understand that this use-case is deferred for a later separate >> discussion, but my point here is that the name and the sem

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:16 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 10:11 PM, Slava Pestov > > wrote: >> However I’m still waiting for Dave or Jordan to chime in with the original justification for the ‘always emit into client’ behavior. IIRC ther

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:21 PM, Jonas B wrote: > > >> >> Yeah, but the compiler could handle NSObject as a special case. Are there >> enough other special cases that it is worth documenting and exposing a >> fragile attribute on classes to the user? >> > > Pitching in here.. currently if y

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> > Yeah, but the compiler could handle NSObject as a special case. Are there > enough other special cases that it is worth documenting and exposing a > fragile attribute on classes to the user? > Pitching in here.. currently if you do something remotely complex with protocols and generics y

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:18 PM, Slava Pestov wrote: > > > >> On Oct 3, 2017, at 10:17 PM, Chris Lattner > > wrote: >> >>> >>> On Oct 3, 2017, at 10:15 PM, Slava Pestov >> > wrote: >>> >>> >>> On Oct 3, 2017, at 10:14 PM, Chris Latt

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:17 PM, Chris Lattner wrote: > >> >> On Oct 3, 2017, at 10:15 PM, Slava Pestov wrote: >> >> >> >>> On Oct 3, 2017, at 10:14 PM, Chris Lattner wrote: >>> >>> On Oct 2, 2017, at 11:11 PM, Slava Pestov wrote: > In any case, even if you’re opposed to these approac

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:15 PM, Slava Pestov wrote: > > > >> On Oct 3, 2017, at 10:14 PM, Chris Lattner wrote: >> >> On Oct 2, 2017, at 11:11 PM, Slava Pestov wrote: In any case, even if you’re opposed to these approaches, I’d love for the “alternatives considered” section to indi

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:11 PM, Slava Pestov wrote: > >>> However I’m still waiting for Dave or Jordan to chime in with the original >>> justification for the ‘always emit into client’ behavior. IIRC there was a >>> resilience-related argument too, but I don’t remember what it is now. >> >> Th

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:14 PM, Chris Lattner wrote: > > On Oct 2, 2017, at 11:11 PM, Slava Pestov wrote: >>> In any case, even if you’re opposed to these approaches, I’d love for the >>> “alternatives considered” section to indicate what the objection is. I am >>> really very concerned that

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Oct 2, 2017, at 11:11 PM, Slava Pestov wrote: >> In any case, even if you’re opposed to these approaches, I’d love for the >> “alternatives considered” section to indicate what the objection is. I am >> really very concerned that you’re causing a keyword/attribute explosion and >> conceptua

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:09 PM, Chris Lattner wrote: > > On Oct 3, 2017, at 9:59 PM, Slava Pestov > wrote: It wouldn't avoid the complexity, because we want the "non-ABI, always-emit-into-client" behavior for the standard library. For the soon-to-be-AB

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Oct 3, 2017, at 9:59 PM, Slava Pestov wrote: >>> It wouldn't avoid the complexity, because we want the "non-ABI, >>> always-emit-into-client" behavior for the standard library. For the >>> soon-to-be-ABI-stable libraries where @inlinable even matters, such as the >>> standard library and App

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: > > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: >> >> The major question I have is “why yet another attribute”. The thread about >> exhaustive/extensible enums is similarly proposin

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > >> >> On Oct 3, 2017, at 9:50 AM, Joe Groff > > wrote: >> >> >> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> We have discussed adding

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > > > >> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> We have discussed adding a "versioned @inlinable" variant that preserves >>> the public entry point for older clients, w

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 11:27 PM, Slava Pestov wrote: > > >> On Oct 2, 2017, at 10:57 PM, Chris Lattner > > wrote: >> >> 1) Why not another level of access control? There is a reasonable argument >> that what you’re doing is making something “more public than public”

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 11:20 PM, Slava Pestov wrote: > > >> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> This semantic doesn’t make sense to me, and I think we need to change it. >>> I think we are better served with the sem

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:14 PM, Jonas B via swift-evolution > wrote: > > > Now I understand that this use-case is deferred for a later separate > discussion, but my point here is that the name and the semantics of this > attribute should be somewhat “forward-compatilble” with this use-case. “

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

I find the following points in the proposal interesting: > Within the scope of a single module, the Swift compiler performs very > aggressive optimization, including full and partial specialization of generic > functions, inlining, and various forms of interprocedural analysis. > On the other ha

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 20:23, Slava Pestov via swift-evolution > wrote: > >> >> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu > > wrote: >> >> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov > > wrote: >> >>> On Oct 2, 2017, at 7:52 PM, Kelvin Ma >>

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution wrote: > > The major question I have is “why yet another attribute”. The thread about > exhaustive/extensible enums is similarly proposing introducing another > one-off way to be enums fragile, and this is directly related just fo

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > >> We have discussed adding a "versioned @inlinable" variant that preserves the >> public entry point for older clients, while making the declaration inlinable >> for newer clients. This will likely be a separate pro

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 12:28 AM, Andrew Trick via swift-evolution > wrote: > > > >> On Oct 2, 2017, at 11:20 PM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution >>> mailto:swift-evolution@s

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 11:20 PM, Slava Pestov via swift-evolution > wrote: > > >> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> This semantic doesn’t make sense to me, and I think we need to change it. >>> I think we are be

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 10:57 PM, Chris Lattner wrote: > > 1) Why not another level of access control? There is a reasonable argument > that what you’re doing is making something “more public than public” or that > you’re making the “body also public”. I’m not strongly in favor of this > desig

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 11:11 PM, Slava Pestov via swift-evolution > wrote: > >> This semantic doesn’t make sense to me, and I think we need to change it. I >> think we are better served with the semantics of “the body may be inlined, >> but doesn’t have to.” > > That is the effect it has toda

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for the review! > On Oct 2, 2017, at 10:57 PM, Chris Lattner wrote: > > This is a great proposal, I’m a strong supporter, but have one question and > one strong push back: > >> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >>

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

This is a great proposal, I’m a strong supporter, but have one question and one strong push back: > On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution > wrote: > Introduction > We propose introducing an @inlinable attribute which exports the body of a > function as part of a module's

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

again, i should reiterate, most users aren’t compiler engineers and so most people use access modifiers as a means of code organization. being able to diagnose when a “private” symbol is being referenced from somewhere it shouldn’t be is very important; the linking and mangling details should be ha

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 9:15 PM, Xiaodi Wu wrote: > > > On Mon, Oct 2, 2017 at 22:23 Slava Pestov > wrote: >> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu > > wrote: >> >> On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov > > wr

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 22:23 Slava Pestov wrote: > On Oct 2, 2017, at 8:06 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov wrote: > >> >> On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: >> >> Is this only a problem with fileprivate or does it extend to private >> members too

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 8:06 PM, Xiaodi Wu wrote: > > On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov > wrote: > >> On Oct 2, 2017, at 7:52 PM, Kelvin Ma > > wrote: >> >> Is this only a problem with fileprivate or does it extend to private memb

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 9:55 PM, Slava Pestov wrote: > > On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: > > Is this only a problem with fileprivate or does it extend to private > members too? I feel like this would be a very valuable feature to support. > > > Private members too. Consider this exam

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 7:52 PM, Kelvin Ma wrote: > > Is this only a problem with fileprivate or does it extend to private members > too? I feel like this would be a very valuable feature to support. Private members too. Consider this example, struct S { private func f() {} } The member S.f m

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Is this only a problem with fileprivate or does it extend to private members too? I feel like this would be a very valuable feature to support. On Mon, Oct 2, 2017 at 9:43 PM, Slava Pestov wrote: > It would be a trivial change to allow @_versioned on private and > fileprivate declarations, but t

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

It would be a trivial change to allow @_versioned on private and fileprivate declarations, but there are two pitfalls to keep in mind: - Private symbols are mangled with a ‘discriminator’ which is basically a hash of the file name. So now it would be part of the ABI, which seems fragile — you c

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Sounds reasonable to me. On Mon, Oct 2, 2017 at 18:54 Taylor Swift wrote: > Right now @_versioned is only for internal declarations. We should have > something similar for private and fileprivate declarations. I think most > people use those modifiers for code organization, not binary resilienc

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Right now @_versioned is only for internal declarations. We should have something similar for private and fileprivate declarations. I think most people use those modifiers for code organization, not binary resilience, so we would do well to make the two intents separate and explicit. On Mon, Oct 2

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 17:41 Taylor Swift wrote: > I think we should try to separate visibility from access control. In other > words, the compiler should be able to see more than the user. I want to be > able to write private and internal code that cannot be called explicitly in > source, but ca

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

This is something I’ve been waiting for for a long time and I’m glad this is finally becoming a reality. This is a big step forward for anyone interested in seeing Swift get core “almost-stdlib” libraries. On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

I think we should try to separate visibility from access control. In other words, the compiler should be able to see more than the user. I want to be able to write private and internal code that cannot be called explicitly in source, but can still be inlined by the compiler. Right now people are do

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

This is unduly restrictive; @_versioned (despite being the wrong spelling) is what we want here. To be callable from an inlinable function, internal things need only be visible in terms of public ABI, not necessarily inlinable, just as public things need only be public and not necessarily inlinable

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Mon, Oct 2, 2017 at 5:21 PM, Slava Pestov wrote: > Thanks for taking a look! > > > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky < > nevin.brackettrozin...@gmail.com> wrote: > > 3. Even though @inlinable will have no effect on declarations which are > not public, we should still allow it

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 2:20 PM, Greg Parker wrote: > > >> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> inlinable declarations can only reference other public declarations. This is >> because they can be emitted into the client bina

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for taking a look! > On Oct 2, 2017, at 2:19 PM, Nevin Brackett-Rozinsky > wrote: > > I am hugely in favor of an @inlinable attribute, and I look forward to its > arrival with relish! > > Some feedback: > > 1. I think “inlinable” is the right spelling: it indicates that something is

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 1:31 PM, Slava Pestov via swift-evolution > wrote: > inlinable declarations can only reference other public declarations. This is > because they can be emitted into the client binary, and are therefore limited > to referencing symbols that the client binary can reference.

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

I am hugely in favor of an @inlinable attribute, and I look forward to its arrival with relish! Some feedback: 1. I think “inlinable” is the right spelling: it indicates that something is *able* to be inlined. 2. If I want to pass an @inlinable function as an argument (say, to map or filter) can

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Today's @available can't be the thing that makes symbols public, since it's also used to affect the availability context for private symbols. The one described in the library evolution document is specifically about marking something available with respect to the current module. So we would want

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Thanks for taking a look. @_versioned is not something we want to keep in the long term. The original idea was to allow @available annotations to be put on internal declarations, which would have the effect of giving their symbols public linkage. I think a follow-up proposal could introduce thi

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

Very much looking forward to this. Any possibility of rolling in some version (ha) of @_versioned so that @inlinable functions can reference internal declarations? On Mon, Oct 2, 2017 at 3:31 PM, Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote: > Hi all, > > Here is a draft p

[swift-evolution] Pitch: Cross-module inlining and specialization

Hi all, Here is a draft proposal that makes public a feature we’ve had for a while. Let me know what you think! Cross-module inlining and specialization ("@inlinable") Proposal: SE- Authors: Slava Pestov , Jordan Rose Review