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

[Xiaodi Wu via swift-evolution]

On Fri, Dec 22, 2017 at 11:12 PM, Slava Pestov  wrote:

>
>
> On Dec 22, 2017, at 7:09 PM, Xiaodi Wu  wrote:
>
> On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner 
> wrote:
>
>>
>> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu  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

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

[Chris Lattner via swift-evolution]

> On Dec 23, 2017, at 2:59 PM, Chris Lattner  wrote:
> 
>>> 
>>> 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.
> 
> Right.  The bug here is with @available(unavailable).  Its design is clearly 
> broken and oxymoronic.  That doesn’t make all of @available broken.

Random thought: I think this all would make more sense if we rename @available 
-> @availability and unavailable -> removed.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Zach Waldowski via swift-evolution]

I’m hugely in favor of a path forward that involves extending existing
language constructs instead of introducing new ones or throwing around a
bunchannotations. I want to say that I like extending `@available`
(because I do), but it kind of breaks my mental model of the flags to
`@available` establishing a sort of “lifecycle” for an entity
(born/introduced foo, deprecated bar, died/removed baz). I know that’s
not official reasoning, but it's helped me explain it to others. (As a
side concern, ABI flags feel too easily forgotten  in the expanded form
of `@available` where you are specifying multiple combos for multiple
platforms.)
Maybe there’s opportunity here for clustering together the purpose of
these ABI features more generally? Others have mentioned parameterizing
the access control keywords, which I personally think aligns well and
will also align well if/when versioning is added to those.
Alternatively, bucketing them together under something like
`@stability(inlinable: foo)` and making sure SourceKit gets autocomplete
for the parameters could be neat. I mention this kind of thing over in
the closed enums thread as deserving a more holistic look as we add a
new axis of syntax features to the language.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me

On Thu, Dec 21, 2017, at 2:14 AM, Chris Lattner via swift-evolution wrote:>> On 
Dec 20, 2017, at 4:19 PM, Ted Kremenek  wrote:>> 
>> The review of "SE-0193 - Cross-module inlining and specialization"
>> begins now and runs through *January 5, 2018*.>> The proposal is available 
>> here:


>>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md>>
>>>  When reviewing a proposal, here are some questions to consider:


>>  * What is your evaluation of the proposal?> I am hugely supportive of the 
>> features that these attributes enable,
> but I think that the spelling of this is absolutely wrong, and I’m
> disappointed that the extensive discussion we’ve had for months about
> this didn’t make it into (at least) the alternatives considered
> section.  Here are my concerns:> 
> *Availability Ranges*
> 
> Both of these attributes will (perhaps not for Swift 5 given the fact
> that these will be new then, but certainly in 5.1 or 6) need to be
> qualified by deployment modifiers.  We’ll need the ability to specify
> not just that a declaration is inlinable or abipublic, but in *which
> versions* of the binary package (that they are defined in) have this
> property.> 
> For example, while perhaps it will be common for a decl to be “born
> inlinable” and just need the form of attribute as specified here, it
> is just as clear that this is not the *only* model we need.  It is
> entirely reasonable (and will be important in the future) to say that
> something “became ABI public in iOS14, became abiPublic in iOS 15, and
> became inlinable in iOS16”.  The use of this will be relatively rare,
> but it is important for the model to support this in time.> 
> Because of this, if we accept the spelling as proposed in this
> proposal, these attributes will need to be generalized to have an
> availability range, e.g.:> 
> @abipublic(iOS 15, *)
> 
> The concern is that this proposal opens the door to have a family of
> attributes each of which have availability information on them, and
> this “family” of attributes will have nothing tying them together into
> a unified framework.> **
> **
> *Pollution of the Attribute Namespace*
> 
> Furthermore, these two attributes are the tip of the iceberg, and the
> core team has spent a lot of time recently discussing the fact there
> are potentially going to be about a dozen attributes similar to these
> (fixed_contents,  global_var_is_directly_addressible, …)  that will
> only be required for binary frameworks.  It is possible that
> @inlinable will be prominent enough to be a global attribute (I
> personally am not sure if it will be commonly used or not, it depends
> a lot on how widely used binary frameworks are).  That said, it is
> clear @abiPublic will not be commonly used, and many attributes that
> follow these will be even more obscure.> 
> This is bad for three reasons: 
> 
> 1) we’re polluting the general attribute namespace with obscure
>things.  Pollution of the attribute namespace may have a marginal
>impact today, but will start to matter if/when we ever get user
>defined attributes.> 
> 2) The other reason is that this provides no general framework to tie
>together these things that affect binary frameworks into a unified
>framework.> 
> 3) Furthermore, I don’t like attributes being a dumping ground for
>weird performance hacks required by binary frameworks.  It is a
>practical necessity that we support these because they are
>extremely important for narrow cases, but we don’t need to put them
>into a syntactically prominent spot in the grammar.> 
> *The name “ABI”*
> 
> A minor point, but the 

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

[Chris Lattner via swift-evolution]

On Dec 22, 2017, at 9:12 PM, Slava Pestov  wrote:
>> 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().

Thanks, that’s a much better example.

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

Right.  The bug here is with @available(unavailable).  Its design is clearly 
broken and oxymoronic.  That doesn’t make all of @available broken.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On Dec 22, 2017, at 9:08 PM, Slava Pestov  wrote:
> 
> 
> 
>> On Dec 22, 2017, at 9:55 AM, Chris Lattner  wrote:
> 
>> When and if we add private cases to enums, we’ll need to be able to 
>> associate an availability range with an “exhaustive” marker.  When/if that 
>> happens, then yes, we should do so through @available(exhaustive: iOS41, *). 
>>The @exhaustive attribute will become sugar for “born exhaustive”, 
>> because in the absence of private cases the availability range doesn’t 
>> matter (AFAIK).
> 
> It still matters if the enum was not “born exhaustive”. Recall that 
> non-exhaustive enums and non-fixed contents structs are address-only types, 
> because we don’t know their size at compile time and so they must be passed 
> indirectly. So if your framework defines a non-exhaustive enum and a function 
> taking or returning this enum, the calling convention will change if the enum 
> becomes exhaustive (unless one of its cases is address-only for some other 
> reason). So we will need to use availability ranges to declare that an enum 
> became exhaustive after the fact. Such an enum will still be treated as 
> non-exhaustive in the calling convention, but can otherwise be manipulated 
> directly (as long as your deployment target is more recent than when it 
> became exhaustive).

Ok, makes sense to me.  This is even more reason to provide a framework that 
scales to these unusual cases. :-)

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 22, 2017, at 7:09 PM, Xiaodi Wu  wrote:
> 
> On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner  > wrote:
> 
>> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu > > 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.

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 22, 2017, at 9:55 AM, Chris Lattner  wrote:

> When and if we add private cases to enums, we’ll need to be able to associate 
> an availability range with an “exhaustive” marker.  When/if that happens, 
> then yes, we should do so through @available(exhaustive: iOS41, *).The 
> @exhaustive attribute will become sugar for “born exhaustive”, because in the 
> absence of private cases the availability range doesn’t matter (AFAIK).

It still matters if the enum was not “born exhaustive”. Recall that 
non-exhaustive enums and non-fixed contents structs are address-only types, 
because we don’t know their size at compile time and so they must be passed 
indirectly. So if your framework defines a non-exhaustive enum and a function 
taking or returning this enum, the calling convention will change if the enum 
becomes exhaustive (unless one of its cases is address-only for some other 
reason). So we will need to use availability ranges to declare that an enum 
became exhaustive after the fact. Such an enum will still be treated as 
non-exhaustive in the calling convention, but can otherwise be manipulated 
directly (as long as your deployment target is more recent than when it became 
exhaustive).

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, Dec 22, 2017 at 6:12 PM, Chris Lattner  wrote:

>
> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu  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?

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

I understand. I was writing about the "abiPublic" example as well, and I
mentioned @available(unavailable) for precisely that reason:

The mess inherent to @available(unavailable) doesn't stem purely from
inelegance in spelling. Rather, @available(anything) looks as though the
"anything" should be a particular kind of API availability, but
@available(unavailable) is _not_ a kind of API availability but precisely
the opposite: unavailability.

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).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

> On Dec 22, 2017, at 1:03 PM, Xiaodi Wu  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

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

[Xiaodi Wu via swift-evolution]

On Fri, Dec 22, 2017 at 2:08 AM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> Hi Chris,
>
> Thanks for reviewing the proposal!
>
> On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Dec 20, 2017, at 4:19 PM, Ted Kremenek  wrote:
>
> The review of "SE-0193 - Cross-module inlining and specialization" begins
> now and runs through *January 5, 2018*.
>
> The proposal is available here:
>
> https://github.com/apple/swift-evolution/blob/master/
> proposals/0193-cross-module-inlining-and-specialization.md
>
> When reviewing a proposal, here are some questions to consider:
>
>-
>
>What is your evaluation of the proposal?
>
> I am hugely supportive of the features that these attributes enable, but I
> think that the spelling of this is absolutely wrong, and I’m disappointed
> that the extensive discussion we’ve had for months about this didn’t make
> it into (at least) the alternatives considered section.  Here are my
> concerns:
>
>
> I’m totally aware of your earlier e-mail thread about tying this in with
> availability and I briefly mentioned it in the ‘future directions’ section.
> I don’t have any objections to your approach and I’d be open to changing
> the proposal if there’s some consensus that this is the right way to go.
>
> Do you think exhaustive enums should be spelled as @available(exhaustive)
> (or @available(exhaustive: …)), also?
>
> Furthermore, these two attributes are the tip of the iceberg, and the core
> team has spent a lot of time recently discussing the fact there are
> potentially going to be about a dozen attributes similar to these
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only
> be required for binary frameworks.
>
>
> Hopefully not a dozen! But yes, there will probably be more than just the
> three currently under discussion.
>
> A minor point, but the specific name “abiPublic” is not great in my
> opinion, because “ABI” is a term of art for compiler hackers.  Most users
> have no idea what ABI means, and those who think they do often don’t.  Very
> few people really understand what “stable ABI” means for example.
>
> It would be better to go with something like “apiPublic” or “symbolPublic”
> or “linkableButNotAccessible” or something else long.  This will not be
> commonly used in user code, so being long and descriptive is a good thing.
>
>
> Several other people in the thread also objected to the name abiPublic.
> I’m not attached to it and I would be open to changing it to something
> better. We just don’t have a clear winner yet...
>
> which generalizes properly when we add version ranges:
>
> @available(iOS 14, *)   // this was introduced in iOS 14
> @available(linkerSymbol: iOS 15, *)  // this decl’s symbol became
> “abiPublic" in iOS 15
> @available(inlinable: iOS 16, *)  // this decl became inlinable in iOS 16
> public func foo() {… }
>
>
> Minor nitpick: public implies ABI-public, so you probably meant the other
> way around, where a symbol became ABI public in iOS 14, then public in iOS
> 15. This is certainly something we need to support and my understanding is
> the equivalent already happens all the time in Objective-C land, where SPI
> becomes API.
>
> 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:

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?

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 

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

[Chris Lattner via swift-evolution]

> On Dec 21, 2017, at 11:08 PM, Slava Pestov  wrote:
>> I am hugely supportive of the features that these attributes enable, but I 
>> think that the spelling of this is absolutely wrong, and I’m disappointed 
>> that the extensive discussion we’ve had for months about this didn’t make it 
>> into (at least) the alternatives considered section.  Here are my concerns:
> 
> I’m totally aware of your earlier e-mail thread about tying this in with 
> availability and I briefly mentioned it in the ‘future directions’ section. I 
> don’t have any objections to your approach and I’d be open to changing the 
> proposal if there’s some consensus that this is the right way to go.
> 
> Do you think exhaustive enums should be spelled as @available(exhaustive) (or 
> @available(exhaustive: …)), also?

When and if we add private cases to enums, we’ll need to be able to associate 
an availability range with an “exhaustive” marker.  When/if that happens, then 
yes, we should do so through @available(exhaustive: iOS41, *).The 
@exhaustive attribute will become sugar for “born exhaustive”, because in the 
absence of private cases the availability range doesn’t matter (AFAIK).

>> Furthermore, these two attributes are the tip of the iceberg, and the core 
>> team has spent a lot of time recently discussing the fact there are 
>> potentially going to be about a dozen attributes similar to these 
>> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
>> required for binary frameworks.
> 
> Hopefully not a dozen! But yes, there will probably be more than just the 
> three currently under discussion.

This is the sort of thing that will creep over the years: lots of sorts of 
people care about performance, and different sorts of people have different 
requirements.  Specific narrow features can have a huge impact on specific 
cases, and we should support those needs.

Look at how many obscure attributes GCC has accreted and what a mess it is, we 
don’t want Swift to look like that in 15 years.

> 
>> which generalizes properly when we add version ranges:
>> 
>>  @available(iOS 14, *)   // this was introduced in iOS 14
>>  @available(linkerSymbol: iOS 15, *)  // this decl’s symbol became 
>> “abiPublic" in iOS 15
>>  @available(inlinable: iOS 16, *)  // this decl became inlinable in iOS 
>> 16
>>  public func foo() {… }
> 
> Minor nitpick: public implies ABI-public, so you probably meant the other way 
> around, where a symbol became ABI public in iOS 14, then public in iOS 15.

You’re right, I got the order backward.  The point stands though :-)

> This is certainly something we need to support and my understanding is the 
> equivalent already happens all the time in Objective-C land, where SPI 
> becomes API.
> 
>> 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 agree.  I’m only concerned that we have a direction that supports the 
availability ranges in a coherent way, I don’t see any urgency to actually 
implement them today.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Slava Pestov via swift-evolution]

> On Dec 21, 2017, at 9:33 AM, Tony Parker via swift-evolution 
>  wrote:
> 
> public
> public(inlinable)
> public(external) // *where we define external to be what abiPublic is now — 
> more bike shedding welcome

I think the downside is that public(external) or whatever @abiPublic becomes 
actually behaves like ‘internal’ as far as name lookup is concerned — a user 
might be confused if they see a public(external) declaration in a source file 
that they cannot actually call.

Also, @inlinable @abiPublic is a totally legit combination; here is an example:

@inlinable @abiPublic func foo() -> Int {
  return 42
}

@inlinable public func bar() -> Int {
  return foo()
}

A client module can call bar() (and inline and specialize it, which in turn 
might inline or specialize foo()). However, it cannot directly call foo(), 
since foo() is not visible in the source language.

To reiterate I’m totally open to alternate spellings for both attributes — I’m 
just not entirely sold on tying it in with the ‘public’ keyword.

Also tying this in with access control still has the problem Chris pointed out, 
where once version ranges are introduced, we have several completely different 
syntaxes and keywords that all take version ranges.

A final data point is that we already have a precedent for <>(<>) — the private(set) and internal(set) syntax for 
properties and subscripts. But here the syntax is used to denote something 
completely different, and it might be confusing to overload it further.

Slava

> 
> - Tony
> 
>> On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> On Dec 20, 2017, at 4:19 PM, Ted Kremenek >> > wrote:
>>> 
>>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>>> now and runs through January 5, 2018.
>>> 
>>> The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>>>  
>>> 
>>> When reviewing a proposal, here are some questions to consider:
>>> 
>>> What is your evaluation of the proposal?
>>> 
>> I am hugely supportive of the features that these attributes enable, but I 
>> think that the spelling of this is absolutely wrong, and I’m disappointed 
>> that the extensive discussion we’ve had for months about this didn’t make it 
>> into (at least) the alternatives considered section.  Here are my concerns:
>> 
>> Availability Ranges
>> 
>> Both of these attributes will (perhaps not for Swift 5 given the fact that 
>> these will be new then, but certainly in 5.1 or 6) need to be qualified by 
>> deployment modifiers.  We’ll need the ability to specify not just that a 
>> declaration is inlinable or abipublic, but in *which versions* of the binary 
>> package (that they are defined in) have this property.  
>> 
>> For example, while perhaps it will be common for a decl to be “born 
>> inlinable” and just need the form of attribute as specified here, it is just 
>> as clear that this is not the *only* model we need.  It is entirely 
>> reasonable (and will be important in the future) to say that something 
>> “became ABI public in iOS14, became abiPublic in iOS 15, and became 
>> inlinable in iOS16”.  The use of this will be relatively rare, but it is 
>> important for the model to support this in time.
>> 
>> Because of this, if we accept the spelling as proposed in this proposal, 
>> these attributes will need to be generalized to have an availability range, 
>> e.g.:
>> 
>>  @abipublic(iOS 15, *)
>> 
>> The concern is that this proposal opens the door to have a family of 
>> attributes each of which have availability information on them, and this 
>> “family” of attributes will have nothing tying them together into a unified 
>> framework.
>> 
>> 
>> Pollution of the Attribute Namespace
>> 
>> Furthermore, these two attributes are the tip of the iceberg, and the core 
>> team has spent a lot of time recently discussing the fact there are 
>> potentially going to be about a dozen attributes similar to these 
>> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
>> required for binary frameworks.  It is possible that @inlinable will be 
>> prominent enough to be a global attribute (I personally am not sure if it 
>> will be commonly used or not, it depends a lot on how widely used binary 
>> frameworks are).  That said, it is clear @abiPublic will not be commonly 
>> used, and many attributes that follow these will be even more obscure.
>> 
>> This is bad for three reasons: 
>> 
>> 1) we’re polluting the general attribute namespace with obscure things.  
>> Pollution of the attribute namespace may have a marginal impact today, but 
>> will start to matter if/when we ever 

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

[Slava Pestov via swift-evolution]

Hi Chris,

Thanks for reviewing the proposal!

> On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 20, 2017, at 4:19 PM, Ted Kremenek > > wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>>  
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> I am hugely supportive of the features that these attributes enable, but I 
> think that the spelling of this is absolutely wrong, and I’m disappointed 
> that the extensive discussion we’ve had for months about this didn’t make it 
> into (at least) the alternatives considered section.  Here are my concerns:

I’m totally aware of your earlier e-mail thread about tying this in with 
availability and I briefly mentioned it in the ‘future directions’ section. I 
don’t have any objections to your approach and I’d be open to changing the 
proposal if there’s some consensus that this is the right way to go.

Do you think exhaustive enums should be spelled as @available(exhaustive) (or 
@available(exhaustive: …)), also?

> Furthermore, these two attributes are the tip of the iceberg, and the core 
> team has spent a lot of time recently discussing the fact there are 
> potentially going to be about a dozen attributes similar to these 
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
> required for binary frameworks.

Hopefully not a dozen! But yes, there will probably be more than just the three 
currently under discussion.

> A minor point, but the specific name “abiPublic” is not great in my opinion, 
> because “ABI” is a term of art for compiler hackers.  Most users have no idea 
> what ABI means, and those who think they do often don’t.  Very few people 
> really understand what “stable ABI” means for example.
> 
> It would be better to go with something like “apiPublic” or “symbolPublic” or 
> “linkableButNotAccessible” or something else long.  This will not be commonly 
> used in user code, so being long and descriptive is a good thing.

Several other people in the thread also objected to the name abiPublic. I’m not 
attached to it and I would be open to changing it to something better. We just 
don’t have a clear winner yet...

> which generalizes properly when we add version ranges:
> 
>   @available(iOS 14, *)   // this was introduced in iOS 14
>   @available(linkerSymbol: iOS 15, *)  // this decl’s symbol became 
> “abiPublic" in iOS 15
>   @available(inlinable: iOS 16, *)  // this decl became inlinable in iOS 
> 16
>   public func foo() {… }

Minor nitpick: public implies ABI-public, so you probably meant the other way 
around, where a symbol became ABI public in iOS 14, then public in iOS 15. This 
is certainly something we need to support and my understanding is the 
equivalent already happens all the time in Objective-C land, where SPI becomes 
API.

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

Slava

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rod Brown via swift-evolution]

Thanks for this reply, Chris. It addresses most of my concerns with the current 
design - scalability (with the attributes), confusion (over the meaning of ABI) 
and changes in declarations as things change.

I think your approach is a far better solution.

> On 21 Dec 2017, at 6:14 pm, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 20, 2017, at 4:19 PM, Ted Kremenek  wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> I am hugely supportive of the features that these attributes enable, but I 
> think that the spelling of this is absolutely wrong, and I’m disappointed 
> that the extensive discussion we’ve had for months about this didn’t make it 
> into (at least) the alternatives considered section.  Here are my concerns:
> 
> Availability Ranges
> 
> Both of these attributes will (perhaps not for Swift 5 given the fact that 
> these will be new then, but certainly in 5.1 or 6) need to be qualified by 
> deployment modifiers.  We’ll need the ability to specify not just that a 
> declaration is inlinable or abipublic, but in *which versions* of the binary 
> package (that they are defined in) have this property.  
> 
> For example, while perhaps it will be common for a decl to be “born 
> inlinable” and just need the form of attribute as specified here, it is just 
> as clear that this is not the *only* model we need.  It is entirely 
> reasonable (and will be important in the future) to say that something 
> “became ABI public in iOS14, became abiPublic in iOS 15, and became inlinable 
> in iOS16”.  The use of this will be relatively rare, but it is important for 
> the model to support this in time.
> 
> Because of this, if we accept the spelling as proposed in this proposal, 
> these attributes will need to be generalized to have an availability range, 
> e.g.:
> 
>   @abipublic(iOS 15, *)
> 
> The concern is that this proposal opens the door to have a family of 
> attributes each of which have availability information on them, and this 
> “family” of attributes will have nothing tying them together into a unified 
> framework.
> 
> 
> Pollution of the Attribute Namespace
> 
> Furthermore, these two attributes are the tip of the iceberg, and the core 
> team has spent a lot of time recently discussing the fact there are 
> potentially going to be about a dozen attributes similar to these 
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
> required for binary frameworks.  It is possible that @inlinable will be 
> prominent enough to be a global attribute (I personally am not sure if it 
> will be commonly used or not, it depends a lot on how widely used binary 
> frameworks are).  That said, it is clear @abiPublic will not be commonly 
> used, and many attributes that follow these will be even more obscure.
> 
> This is bad for three reasons: 
> 
> 1) we’re polluting the general attribute namespace with obscure things.  
> Pollution of the attribute namespace may have a marginal impact today, but 
> will start to matter if/when we ever get user defined attributes.  
> 
> 2) The other reason is that this provides no general framework to tie 
> together these things that affect binary frameworks into a unified framework. 
>  
> 
> 3) Furthermore, I don’t like attributes being a dumping ground for weird 
> performance hacks required by binary frameworks.  It is a practical necessity 
> that we support these because they are extremely important for narrow cases, 
> but we don’t need to put them into a syntactically prominent spot in the 
> grammar.
> 
> The name “ABI”
> 
> A minor point, but the specific name “abiPublic” is not great in my opinion, 
> because “ABI” is a term of art for compiler hackers.  Most users have no idea 
> what ABI means, and those who think they do often don’t.  Very few people 
> really understand what “stable ABI” means for example.
> 
> It would be better to go with something like “apiPublic” or “symbolPublic” or 
> “linkableButNotAccessible” or something else long.  This will not be commonly 
> used in user code, so being long and descriptive is a good thing.
> 
> 
> Counterproposal:
> 
> There is a simple way to address the two concerns above: we already have a 
> framework for handling API evolution with binary frameworks, the @available 
> attribute.  We can spell these “attributes” as:
> 
>   @available(inlinable)   // this symbol has been inlinable since it was 
> introduced
> 
> which generalizes properly when we add version ranges:
> 
>   @available(iOS 14, *)   // this was introduced in iOS 14
>   

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

[Tony Parker via swift-evolution]

I was going to write up a detailed response to this as well, but Chris did it 
for me.

In general, I agree that we need the feature.

However, I believe that the name “ABI” is too specific and does not accomplish 
the primary purpose of naming this thing — which is to allow people to 
understand what it means by reading it.

I agree that scoping these attributes inside the availability declaration is 
the best option. As a framework author, the notion of availability is of 
primary importance, and having things which affect how my clients see my code 
be part of that general concept makes the most sense. My second choice would be 
to scope it inside the “public” declaration, as in:

public
public(inlinable)
public(external) // *where we define external to be what abiPublic is now — 
more bike shedding welcome

- Tony

> On Dec 20, 2017, at 11:14 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 20, 2017, at 4:19 PM, Ted Kremenek > > wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>>  
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> I am hugely supportive of the features that these attributes enable, but I 
> think that the spelling of this is absolutely wrong, and I’m disappointed 
> that the extensive discussion we’ve had for months about this didn’t make it 
> into (at least) the alternatives considered section.  Here are my concerns:
> 
> Availability Ranges
> 
> Both of these attributes will (perhaps not for Swift 5 given the fact that 
> these will be new then, but certainly in 5.1 or 6) need to be qualified by 
> deployment modifiers.  We’ll need the ability to specify not just that a 
> declaration is inlinable or abipublic, but in *which versions* of the binary 
> package (that they are defined in) have this property.  
> 
> For example, while perhaps it will be common for a decl to be “born 
> inlinable” and just need the form of attribute as specified here, it is just 
> as clear that this is not the *only* model we need.  It is entirely 
> reasonable (and will be important in the future) to say that something 
> “became ABI public in iOS14, became abiPublic in iOS 15, and became inlinable 
> in iOS16”.  The use of this will be relatively rare, but it is important for 
> the model to support this in time.
> 
> Because of this, if we accept the spelling as proposed in this proposal, 
> these attributes will need to be generalized to have an availability range, 
> e.g.:
> 
>   @abipublic(iOS 15, *)
> 
> The concern is that this proposal opens the door to have a family of 
> attributes each of which have availability information on them, and this 
> “family” of attributes will have nothing tying them together into a unified 
> framework.
> 
> 
> Pollution of the Attribute Namespace
> 
> Furthermore, these two attributes are the tip of the iceberg, and the core 
> team has spent a lot of time recently discussing the fact there are 
> potentially going to be about a dozen attributes similar to these 
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
> required for binary frameworks.  It is possible that @inlinable will be 
> prominent enough to be a global attribute (I personally am not sure if it 
> will be commonly used or not, it depends a lot on how widely used binary 
> frameworks are).  That said, it is clear @abiPublic will not be commonly 
> used, and many attributes that follow these will be even more obscure.
> 
> This is bad for three reasons: 
> 
> 1) we’re polluting the general attribute namespace with obscure things.  
> Pollution of the attribute namespace may have a marginal impact today, but 
> will start to matter if/when we ever get user defined attributes.  
> 
> 2) The other reason is that this provides no general framework to tie 
> together these things that affect binary frameworks into a unified framework. 
>  
> 
> 3) Furthermore, I don’t like attributes being a dumping ground for weird 
> performance hacks required by binary frameworks.  It is a practical necessity 
> that we support these because they are extremely important for narrow cases, 
> but we don’t need to put them into a syntactically prominent spot in the 
> grammar.
> 
> The name “ABI”
> 
> A minor point, but the specific name “abiPublic” is not great in my opinion, 
> because “ABI” is a term of art for compiler hackers.  Most users have no idea 
> what ABI means, and those who think they do often don’t.  Very few people 
> really understand what “stable ABI” means for 

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

[Goffredo Marocchi via swift-evolution]

+1 thanks for your response Chris, it seems to me that it addresses the need 
this PR is trying to address and it does make it so in a scalable way. I would 
strongly hope your feedback is added to the proposal and shapes the final 
solution.

Sent from my iPhone

> On 21 Dec 2017, at 07:14, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 20, 2017, at 4:19 PM, Ted Kremenek  wrote:
>> 
>> The review of "SE-0193 - Cross-module inlining and specialization" begins 
>> now and runs through January 5, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> I am hugely supportive of the features that these attributes enable, but I 
> think that the spelling of this is absolutely wrong, and I’m disappointed 
> that the extensive discussion we’ve had for months about this didn’t make it 
> into (at least) the alternatives considered section.  Here are my concerns:
> 
> Availability Ranges
> 
> Both of these attributes will (perhaps not for Swift 5 given the fact that 
> these will be new then, but certainly in 5.1 or 6) need to be qualified by 
> deployment modifiers.  We’ll need the ability to specify not just that a 
> declaration is inlinable or abipublic, but in *which versions* of the binary 
> package (that they are defined in) have this property.  
> 
> For example, while perhaps it will be common for a decl to be “born 
> inlinable” and just need the form of attribute as specified here, it is just 
> as clear that this is not the *only* model we need.  It is entirely 
> reasonable (and will be important in the future) to say that something 
> “became ABI public in iOS14, became abiPublic in iOS 15, and became inlinable 
> in iOS16”.  The use of this will be relatively rare, but it is important for 
> the model to support this in time.
> 
> Because of this, if we accept the spelling as proposed in this proposal, 
> these attributes will need to be generalized to have an availability range, 
> e.g.:
> 
>   @abipublic(iOS 15, *)
> 
> The concern is that this proposal opens the door to have a family of 
> attributes each of which have availability information on them, and this 
> “family” of attributes will have nothing tying them together into a unified 
> framework.
> 
> 
> Pollution of the Attribute Namespace
> 
> Furthermore, these two attributes are the tip of the iceberg, and the core 
> team has spent a lot of time recently discussing the fact there are 
> potentially going to be about a dozen attributes similar to these 
> (fixed_contents,  global_var_is_directly_addressible, …)  that will only be 
> required for binary frameworks.  It is possible that @inlinable will be 
> prominent enough to be a global attribute (I personally am not sure if it 
> will be commonly used or not, it depends a lot on how widely used binary 
> frameworks are).  That said, it is clear @abiPublic will not be commonly 
> used, and many attributes that follow these will be even more obscure.
> 
> This is bad for three reasons: 
> 
> 1) we’re polluting the general attribute namespace with obscure things.  
> Pollution of the attribute namespace may have a marginal impact today, but 
> will start to matter if/when we ever get user defined attributes.  
> 
> 2) The other reason is that this provides no general framework to tie 
> together these things that affect binary frameworks into a unified framework. 
>  
> 
> 3) Furthermore, I don’t like attributes being a dumping ground for weird 
> performance hacks required by binary frameworks.  It is a practical necessity 
> that we support these because they are extremely important for narrow cases, 
> but we don’t need to put them into a syntactically prominent spot in the 
> grammar.
> 
> The name “ABI”
> 
> A minor point, but the specific name “abiPublic” is not great in my opinion, 
> because “ABI” is a term of art for compiler hackers.  Most users have no idea 
> what ABI means, and those who think they do often don’t.  Very few people 
> really understand what “stable ABI” means for example.
> 
> It would be better to go with something like “apiPublic” or “symbolPublic” or 
> “linkableButNotAccessible” or something else long.  This will not be commonly 
> used in user code, so being long and descriptive is a good thing.
> 
> 
> Counterproposal:
> 
> There is a simple way to address the two concerns above: we already have a 
> framework for handling API evolution with binary frameworks, the @available 
> attribute.  We can spell these “attributes” as:
> 
>   @available(inlinable)   // this symbol has been inlinable since it was 
> introduced
> 
> which generalizes properly when we add version ranges:
> 
>   @available(iOS 14, *)   // this was introduced in iOS 14
>   

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

[Chris Lattner via swift-evolution]

> On Dec 20, 2017, at 4:19 PM, Ted Kremenek  wrote:
> 
> The review of "SE-0193 - Cross-module inlining and specialization" begins now 
> and runs through January 5, 2018.
> 
> The proposal is available here:
> 
> https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
I am hugely supportive of the features that these attributes enable, but I 
think that the spelling of this is absolutely wrong, and I’m disappointed that 
the extensive discussion we’ve had for months about this didn’t make it into 
(at least) the alternatives considered section.  Here are my concerns:

Availability Ranges

Both of these attributes will (perhaps not for Swift 5 given the fact that 
these will be new then, but certainly in 5.1 or 6) need to be qualified by 
deployment modifiers.  We’ll need the ability to specify not just that a 
declaration is inlinable or abipublic, but in *which versions* of the binary 
package (that they are defined in) have this property.  

For example, while perhaps it will be common for a decl to be “born inlinable” 
and just need the form of attribute as specified here, it is just as clear that 
this is not the *only* model we need.  It is entirely reasonable (and will be 
important in the future) to say that something “became ABI public in iOS14, 
became abiPublic in iOS 15, and became inlinable in iOS16”.  The use of this 
will be relatively rare, but it is important for the model to support this in 
time.

Because of this, if we accept the spelling as proposed in this proposal, these 
attributes will need to be generalized to have an availability range, e.g.:

@abipublic(iOS 15, *)

The concern is that this proposal opens the door to have a family of attributes 
each of which have availability information on them, and this “family” of 
attributes will have nothing tying them together into a unified framework.


Pollution of the Attribute Namespace

Furthermore, these two attributes are the tip of the iceberg, and the core team 
has spent a lot of time recently discussing the fact there are potentially 
going to be about a dozen attributes similar to these (fixed_contents,  
global_var_is_directly_addressible, …)  that will only be required for binary 
frameworks.  It is possible that @inlinable will be prominent enough to be a 
global attribute (I personally am not sure if it will be commonly used or not, 
it depends a lot on how widely used binary frameworks are).  That said, it is 
clear @abiPublic will not be commonly used, and many attributes that follow 
these will be even more obscure.

This is bad for three reasons: 

1) we’re polluting the general attribute namespace with obscure things.  
Pollution of the attribute namespace may have a marginal impact today, but will 
start to matter if/when we ever get user defined attributes.  

2) The other reason is that this provides no general framework to tie together 
these things that affect binary frameworks into a unified framework.  

3) Furthermore, I don’t like attributes being a dumping ground for weird 
performance hacks required by binary frameworks.  It is a practical necessity 
that we support these because they are extremely important for narrow cases, 
but we don’t need to put them into a syntactically prominent spot in the 
grammar.

The name “ABI”

A minor point, but the specific name “abiPublic” is not great in my opinion, 
because “ABI” is a term of art for compiler hackers.  Most users have no idea 
what ABI means, and those who think they do often don’t.  Very few people 
really understand what “stable ABI” means for example.

It would be better to go with something like “apiPublic” or “symbolPublic” or 
“linkableButNotAccessible” or something else long.  This will not be commonly 
used in user code, so being long and descriptive is a good thing.


Counterproposal:

There is a simple way to address the two concerns above: we already have a 
framework for handling API evolution with binary frameworks, the @available 
attribute.  We can spell these “attributes” as:

@available(inlinable)   // this symbol has been inlinable since it was 
introduced

which generalizes properly when we add version ranges:

@available(iOS 14, *)   // this was introduced in iOS 14
@available(linkerSymbol: iOS 15, *)  // this decl’s symbol became 
“abiPublic" in iOS 15
@available(inlinable: iOS 16, *)  // this decl became inlinable in iOS 
16
public func foo() {… }

and allows us to bury weird hacks like “abiPublic” and the other even more 
obscure things that are coming outside of the global attribute namespace:

@available(global_var_is_directly_accessible: iOS 15, *)
public var myDispatchOnceToken : ...


Given this unified framework for handling ABI evolution, we can then separately 
discuss which