On Fri, Dec 22, 2017 at 11:12 PM, Slava Pestov <spes...@apple.com> wrote:
> > > On Dec 22, 2017, at 7:09 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner <clatt...@nondot.org> > wrote: > >> >> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >> In short, respectfully request that you at least add this approach to the >>> "alternatives considered” section. >>> >>> >>> So, does anyone have any strong objections to Chris’s proposal? >>> >>> From an implementation standpoint, reworking the parser to parse >>> @available(inlinable) and @available(fixedContents) or whatever would be >>> straightforward. I would still like to punt the version range part of this >>> to a future proposal, though. >>> >>> >> I wish I had more time to compose a fully thought-out reply, but that's >> not going to happen in a little while because of outside constraints, so >> I'll spill a few thoughts here: >> >> >> No rush, no worries, enjoy the holiday! >> >> I'm not a great fan of the @available(inlinable) notation. >> >> For one, I have a hard time reasoning how Swift would behave when >> inlinability is tied to OS version. In this example, if the *app* (as >> opposed to the library) is compiled (as opposed to run) on iOS 16+, then >> the *library method* would potentially be emitted into the app, but if >> compiled on iOS 15 it wouldn't? Huh? >> >> >> No: availability information kicks in based on what you are *deploying* >> to, not what you’re compiling on. >> >> I expect that this stuff will be extremely rarely used in practice, but >> here’s an example: >> >> iOS15 declares this public: >> >> public void foo() { >> bar() >> } >> >> iOS16 wants to promote foo to inlinable, but knows that the inlined body >> doesn’t work with iOS15, because iOS15 needs the call to bar to happen (for >> whatever reason) >> >> @available(inlinable: iOS16) >> public void foo() { >> >> // nothing needed on iOS16 or later. >> >> } >> > > Deployment platform makes more sense, but I still can't envision a real > use case. What sorts of `bar()` would hypothetically be necessary for iOS > 15 but not 16? Why would a third-party library need to increase its > inlining availability for an app based on deployment platform? > > > A better example would be if bar() was itself only available in iOS 16: > > @available(iOS 15) > @available(inlinable: iOS 16) > public func foo() { > bar() > } > > @available(iOS 16) > public func bar() { … } > > Suppose your app calls foo() and deploys to iOS 15. Then you cannot inline > foo(), because bar() does not exist on iOS 15. (Presumably, foo() had a > different implementation on iOS 15). But if you’re deploying to iOS 16, all > is well, and you can inline foo(), which results in your app directly > calling bar(). > > I'm quite sure that the reason you inverted your "abiPublic" example is > because of the same issue. Intuitively, you would want to mark something as > "available" in version N and then maybe some special kind of "available" in > version N+1 (which @available(inlinable) would be). But > @available(linkerSymbol), as you spell it, suffers from a similar problem > to that of @available(unavailable): it's _not_ a special kind of API > availability, but rather indicates that something is less-than-available. > That is, you would use it to indicate that something is available as ABI > but not as API. In that sense, it extends the "mess" we have with > @available(unavailable). > > > I don’t think it’s quite the same thing as @available(unavailable). An > @available(abiPublic) symbol would still be declared to have internal > visibility, so in this case the @available attribute makes it strictly more > visible than it would be without. We’re not going to spell it as > ‘@available(abiPublic) public’, which indeed would be confusing because the > symbol is not actually public at the source level. > In Chris's example, it's an annotation of a public API that was once internal in a previous version: @available(apiPublic: iOS 14) @available(iOS 15) @available(inlinable: iOS 16) public func foo() { ... } This is a sensible use, but it shows how we get to exactly the "indeed confusing" situation you write about above: here, @available(apiPublic) elevates the API above internal but below public *even when it annotates a public API*.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution