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] [REVIEW] SE-0193 - Cross-module inlining and specialization

[Slava Pestov via swift-evolution]

> On Dec 22, 2017, at 1:50 AM, Johannes Weiß  wrote:
> 
> totally agree that these attributes are necessary, they should be in Swift as 
> soon as we bike shedded the right name. But to prevent them from being placed 
> everywhere without thinking I propose to introduce a compiler mode at the 
> same time.
> Performance testing is hard and takes time. So I'm pretty sure that as soon 
> as one @abiPublic/@inlinable has proven to improve performance, library 
> authors will just start putting them anywhere as there's no downside besides 
> making the code harder to read.
> 
> What is the downside of bringing the attributes and the compiler mode at the 
> same time. Am I massively underestimating the amount of work required for 
> such mode?

ABI stability for the standard library is our top priority for Swift 5. While 
adding a ‘completely fragile’ compiler mode should be straightforward in 
theory, the devil is in the details, and I don’t think we can commit to 
delivering this feature any time soon.

> Cool. Just to be sure I understand you correctly: Assuming your proposal gets 
> implemented as proposed, a function that does _not_ have the @inlinable 
> attribute it won't be specialised across modules, ever. Correct?

That is correct. This is already the behavior today, so there’s no change here.

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] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

[Brent Royal-Gordon via swift-evolution]

> On Dec 21, 2017, at 10:33 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
> The main blocker was that such a case becomes untestable (see also "Testing 
> invalid cases").

You can always make it testable through appropriate factoring—for example, have 
the `future` case call a helper function, and then explicitly invoke that 
helper function to test its behavior. That won't give you coverage of the 
`future` case itself, but there's nothing on the table that will (not even 
`default` when all the existing cases are covered).

-- 
Brent Royal-Gordon
Architechies

___
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 the notation is
not 

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

[Paul Cantrell via swift-evolution]

> On Dec 22, 2017, at 1:29 AM, Slava Pestov  wrote:
> 
>> On Dec 21, 2017, at 12:42 PM, Paul Cantrell > > wrote:
>> 
>> 1. Presumably the portions of A inlined into B and C remain sensitive to the 
>> version-specific memory layout of A? Or will ABI stability mean that the 
>> compiler can magically rearrange memory offsets in already-compiled code 
>> when the layout changes? (Apologies if this is a too-obvious question; this 
>> part of Swift is all a mystery to me.)
> 
> There is not really a notion of memory layout at the level of an entire 
> module. For structs, classes and enums, you pretty much have the same 
> concerns with both inlinable and non-inlinable functions — if the framework 
> author can change the stored property layout of a struct or class (or adds a 
> case to an enum), code that manipulates these data types must not make any 
> compile-time assumptions that might be invalidated at runtime with a newer 
> version of the framework.
> 
> This is basically what the upcoming @fixedContents proposal for structs is 
> about — giving framework authors a way to trade future flexibility for 
> performance by allowing the compiler to make assumptions about the layout of 
> a struct as it is written at compile-time. The @exhaustive proposal for enums 
> has a similar implementation angle, but is of course more interesting because 
> it affects the source language as well, with switch statements.
> 
> We don’t plan on any kind of resilience opt-out for classes — already in 
> shipping Swift compilers, accesses to stored properties of classes use 
> accessor methods and not direct access across module boundaries.

Thanks, this is quite helpful.

My underlying concern here is that understanding even what kinds of breakage 
are _possible_ due to inlining currently requires fairly detailed knowledge of 
Swift’s guts, and even the best-intentioned among us are going to get it wrong. 
We’ll need tool help reasoning about it, not just documentation. At least I 
know _I_ will! (Actually, I’ll probably just avoid @inlinable altogether, but 
I’d certainly need tool help if I ever do use it.)

> 
>> 2. Is there some class of statically identifiable breaking changes that the 
>> compiler does (or should) detect to flag incompatible inlined code? e.g. 
>> some version of A inlined into B references A.foo, then A.foo is deleted in 
>> a later version of A, so mixing older B with newer A in a project gives a 
>> compile- or link-time error?
> 
> This is what an “ABI differ” tool would achieve, but like I said it has not 
> yet been designed.

Yes. I would certainly use such a tool if it existed, and not just for dealing 
with @inlinable.

> 
>> 3. Does this need some sort of poison pill feature for other sorts of 
>> breaking changes that are not statically detectable? e.g. invariants of a 
>> data structure in A change in release 2.0, so the author of A says “it is an 
>> error to include A ≥2.0 in any project that inlined any of my code from a 
>> version <2.0.” Is this what you were getting at with the mention of 
>> @inlinable(2.0) in the proposal? Sounded like that part was about something 
>> else, but I didn’t really grasp it tbh.
> 
> This is an interesting point and I think it is outside of the scope of these 
> proposals. If the ABI of a library changes in an incompatible manner and 
> previous binaries are no longer compatible with it, you should think of it as 
> shipping a *new* library, either by changing it’s name or bumping the major 
> version number, so that the dynamic linker prevents the client binary from 
> being run in the first place.

If the compiler/linker actively prohibits mixing of inlined code from different 
major version numbers, that eases my concern somewhat. A library author isn’t 
stuck with an ABI-sensitive mistake until the end of time.

> 
>> Yes, frameworks+app built simultaneously are clearly the more common case. 
>> Though Carthage seems to be champing at the bit to create this problem, 
>> since it added a feature to download prebuilt binaries long before ABI 
>> stability! I can easily imagining this feature spreading via word of mouth 
>> as a “secret go faster switch,” and causing no end of problems in the wild.
> 
> Perhaps, but I still think it is strictly better to formalize the feature 
> through a proposal and document the pitfalls carefully — the underscored 
> attribute is already spreading through word of mouth and in the absence of 
> official documentation the potential for abuse is greater.

Fair point. Making this feature public & documented, albeit ill understood, is 
a safety improvement over undocumented & even iller-understood!

> 
>> It might be safer — and better match the understanding of the typical user — 
>> to have @inlinable assume by default that an inlined version of any given 
>> method is only valid only for the specific version of the module it was 
>> inlined from. The compiler would by default flag any ve

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] [Review] SE 0192 - Non-Exhaustive Enums

[Cheyo Jose Jimenez via swift-evolution]

> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez  wrote:
> 
> 
> 
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>>  wrote:
>> 
>> The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
>> January 3, 2018.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>> Reviews are an important part of the Swift evolution process. All review 
>> feedback should be sent to the swift-evolution mailing list at:
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> When replying, please try to keep the proposal link at the top of the 
>> message:
>> 
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>> ...
>> Reply text
>> ...
>> Other replies
>> What goes into a review of a proposal?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. 
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> +1 except for the name. @frozenExposed @fixedMembers @frozenMembers. 
> preferably something that aligns with the other notion of not being able to 
> add public members to structs. This will help treat structs with static 
> members in the same way which would be ideal.  I don't think enums should 
> have their own attitude.
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> 
> don't know. im not a library author. ill defer to other library authors. 

I want to revise my review here. While I am not a library author I am a library 
consumer. 

Having the ability treat a non exhaustive enum as exhaustive should be 
introduced with this. I like the idea of a 
`final switch`

I think it communicate clearly that I want this to be treated as exhaustive 
even if it is already exhaustive. Having something like future, unknowns would 
be weird to me. 

Another option would be being able to cast a enum as exhaustive. I am not sure 
how that would work. I do not like switch!  

>> Does this proposal fit well with the feel and direction of Swift?
>> 
> yes. 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> 
> n/a
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> 
> followed the previous discussion. read the proposal. 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

[Brent Royal-Gordon via swift-evolution]

> On Dec 21, 2017, at 10:02 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> I would love to see some sort of formal API versioning that we could do 
> instead in libraries, along with easy runtime support for checking the linked 
> version of libraries, making it easy to strategize implementations based on 
> version, etc.

This feature would have to be applied not only to switching on enums, but to 
*every* operation on a resilient value. In practice, I think it generalizes to 
one of:

1. Pass a linked-against version number to every resilient call.

2. Have a way to fetch a substitute witness table for a given module 
version.

Either one of these seems like a tall order.

-- 
Brent Royal-Gordon
Architechies

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

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

[Djura Retired Hunter via swift-evolution]

Many styles of programming can take advantage of if/else and switch/case being 
actual expressions (actually, these are all special cases of the very general 
concept of "folding"). We don't have this in Swift, and I have occasion to be 
bothered by this almost on a daily basis in my work, especially when I try to 
be "concise", something for which Swift should be champion.

The best possible outcome would be for Swift to have pattern matching as a 
proper evaluated expression, but I would accept a new operator that takes 
advantage of some custom compiler magic, because the use cases are so many and 
the convenience would be so great.

As Colin Barret said, this is a very popular thing in many modern languages.


Elviro

> Il giorno 20 dic 2017, alle ore 19:32, Colin Barrett via swift-evolution 
>  ha scritto:
> 
> This would be easily solved if pattern matching was available as an 
> expression, such as in Haskell, OCaml / Standard ML, and Scala / Kotlin. :-)
> 
>> On Dec 20, 2017, at 11:44 AM, Ethan Diamond via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hello everyone,
>> 
>> One major pain point I've run into with Swift is the inability to evaluate 
>> the case of an enum that has associated values in a way that just returns a 
>> bool. We've been given the ability in a switch statement:
>> 
>> enum Enum {
>>case a(param: String)
>>case b(param: String)
>> }
>> 
>> let enumeration: Enum = a(param: "Hi")
>> switch enumeration {
>> case a:
>>   // Do something
>> case b:
>>   // Do something
>> }
>> 
>> We'e been given the ability in the context of an if statement:
>> 
>> enum Enum {
>>case a(param: String)
>>case b(param: String)
>> }
>> 
>> let enumeration: Enum = a(param: "Hi")
>> 
>> if case .a = enumeration { 
>> // Do something
>> }
>> 
>> But without a basic was of getting a bool for if an enum is a given case, 
>> here's a list of things I can't do:
>> 
>> Where statements:
>> 
>> enum Enum {
>>case a(param: Enum2)
>>case b(param: Enum2)
>> }
>> 
>> enum Enum2 {
>> case c(param: String)
>> case d(param: String)
>> }
>> 
>> let enumeration: Enum = a(param: "Hi")
>> switch enumeration {
>> case a(let inner) where [INNER CASE IS .c]
>> }
>> 
>> -
>> 
>> Filter an array for a certain case:
>> 
>> Expertly explained by Erica Sadun here: 
>> http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/
>>  
>> 
>> 
>> -
>> 
>> Nicely set a UIButton to hidden if an enum is a certain case:
>> 
>> enum State {
>> case `default`
>> case searching(results: [Result])
>> }
>> 
>> myButton.isHidden = [STATE IS .searching]
>> 
>> -
>> 
>> I've run into this issue a ton of times because I tend to represent my views 
>> a State enums. I haven't seen anything on the board for plans for solving 
>> this issue, thought. Has there been any discussion about addressing it? 
>> Ideally I'd be able to do this:
>> 
>> enum Enum {
>>case a(param: String)
>>case b(param: String)
>> }
>> 
>> let enumeration: Enum = a(param: "Hi")
>> 
>> case .a = enumeration // Bool
>> case .a(let param) = enumeration // Bool, assigns "Hi" to "param"
>> 
>> Thanks!
>> Ethan
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

[Rod Brown via swift-evolution]

I think you make a fair point here - either case is currently untestable in a 
non-exhaustive enum.

Perhaps this pushes harder on the “future” case and a way we can test this in 
Unit Tests when we @testable import other frameworks to simulate an additional 
case.

> On 22 Dec 2017, at 5:36 am, Kevin Nattinger via swift-evolution 
>  wrote:
> 
>>> [...]
>> 
>> Hi, Nacho. This is discussed in the proposal as "'future' cases" under 
>> "Alternatives considered". The main blocker was that such a case becomes 
>> untestable (see also "Testing invalid cases"). That didn't seem like an 
>> acceptable state of affairs to me or to the people I had originally 
>> discussed the proposal with, but maybe the community feels differently?
> 
> As you state in the proposal, using `default` instead is exactly as 
> untestable, in exactly the same way. Using that as an argument against future 
> but not default is disingenuous. And default additionally introduces the 
> enormous issue of killing compile-time safety, while future does not..
> 
>> 
>> I would love if someone could think of something I haven't yet; by no means 
>> do I think I'm the only one who can have ideas in this space.
>> 
>> Jordan
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

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

[Johannes Weiß via swift-evolution]

Hi Slava,

> On 22 Dec 2017, at 7:13 am, Slava Pestov  wrote:
> 
> Hi Johannes,
> 
> Thanks for reviewing this proposal!
> 
>> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>>  wrote:
> 
>> The library I'm working on will presumably never have stable ABI as you'd 
>> naturally build it with your application. However we also don't want to miss 
>> on the cross-module optimisation & specialisation and I suspect there are 
>> quite a few (mostly open-source) libraries in the same space. I'm pretty 
>> sure everybody would just end up littering their code with 
>> @abiPublic/@inlinable (or the @available(...) syntax Chris Lattner proposed) 
>> without actually meaning that.
>> 
>> Summing up: I think this feature is crucial but shouldn't come without a 
>> compiler "where all declarations become implicitly @inlinable, and all 
>> private and internal declarations become @abiPublic". I really don't want to 
>> litter the code with attributes that aren't what I mean. (basically `swift 
>> build --global-resilience-domain`) Having this compiler mode also makes 
>> these attributes IMHO really niche and therefore I can only sympathise 
>> with's Chris' sentiment to not litter the global attribute namespace.
> 
> I agree that a ‘completely non-resilient’ compiler mode would be great when 
> building libraries that are always shipped together, and I hope Swift gains 
> such a feature one day, possibly built on top of the very infrastructure used 
> to implement this proposal!

Cool. I just meant that the compiler mode and the public (as in 
non-underscored) attributes should go hand in hand to not tempt people into 
littering their code without thinking.


> However, the goal of this proposal is to formalize some language features 
> that already exist and are used by the standard library. Clearly making 
> everything fragile is a non-starter for the standard library in an ABI-stable 
> world.

totally agree that these attributes are necessary, they should be in Swift as 
soon as we bike shedded the right name. But to prevent them from being placed 
everywhere without thinking I propose to introduce a compiler mode at the same 
time.
Performance testing is hard and takes time. So I'm pretty sure that as soon as 
one @abiPublic/@inlinable has proven to improve performance, library authors 
will just start putting them anywhere as there's no downside besides making the 
code harder to read.

What is the downside of bringing the attributes and the compiler mode at the 
same time. Am I massively underestimating the amount of work required for such 
mode?


> I do hope that this attribute is not abused in the manner in which you 
> describe, but I’m not sure the potential for abuse is reason enough to not 
> run the proposal — people are already using the underscored attribute today, 
> risking source breakage and bugs due to insufficient test coverage in the 
> future.

> 
>> C(++) as described in the proposal and Haskell 
>> (https://wiki.haskell.org/Inlining_and_Specialisation), where {-# INLINABLE 
>> myFunction #-} (quoting the docs) causes exactly two things to happens.
>> 
>>  • The function's (exact) definition is included in the interface file 
>> for the module.
>>  • The function will be specialised at use sites -- even across modules.
>> Note that [the Haskell compiler] GHC is no more keen to inline an INLINABLE 
>> function than any other.
> 
> Note that Swift’s compiler is the same — @inlinable does not influence 
> optimizer decisions to inline or not.

Cool, that's what I suspected. Good to know that the Swift & GHC attributes are 
the same and even the name is :).
So we just need -fspecialise-aggressively 🤓.


> Also currently the proposal is implemented by binary serialization of the SIL 
> IR, but nothing in it precludes serializing inlinable function bodies as 
> source code in the future — in fact we are likely to go in that direction if 
> we implement the proposed textual ‘stable’ module format.

Cool. Just to be sure I understand you correctly: Assuming your proposal gets 
implemented as proposed, a function that does _not_ have the @inlinable 
attribute it won't be specialised across modules, ever. Correct?


-- Johannes

> 
> Slava
> 

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