> 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. } The vastly most common case is that something is defined as inlinable and always inlinable, that’s why the @available(inlinable) form is important, and why it may make sense to further sugar that default case to @inlinable. > Second--and perhaps this is not a common opinion--I've always thought that > the @available notation was disastrous in terms of readability, especially > when it comes to @available(unavailable) and the meaning of the asterisk. > Every time, I have to run and look up whether it means the method is in fact > available or unavailable for non-listed platforms. Again, with the > understanding that this is not a fully formed thought, I have to say that I > feel this is taking a readable and fairly straightforward concept > (@inlinable) and adding on too many layers of baggage. That it was easy for > Swift's creator to inadvertently invert the intended annotations in his > initial example is, to me, a pretty good demonstration that the notation is > not at all user-friendly. I agree that @available(unavailable) is a mess, this direction doesn’t make it worse though. However, the thing I inverted wasn’t the syntax, it was the “abipublic” example. abipublic is a confusing concept no matter how it is spelled. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution