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

[Slava Pestov via swift-evolution]

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

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

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

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

> 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 version mixing as an 
> error, and require an explicit statement of compatibility intent for each 
> piece of inlinable code to opt in to the danger zone of mixed versions.

How would this be implemented?

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 21, 2017, at 11:05 AM, Greg Titus via swift-evolution 
>  wrote:
> 
> I come from a perspective similar to Johannes, in that: for my work we are 
> interested in the performance improvements of cross-module optimization and 
> specialization but we regularly rebuild frameworks along with apps and 
> explicitly don’t need ABI versioning. Unlike him, I’m not that concerned with 
> littering attributes for inlinability around, but for our purposes the 
> original proposed spelling of @inlinable/@abiPublic or even better, Tony’s 
> proposed public(inlinable) makes for easier understanding when reading the 
> code than Chris’s proposed @available() extensions, which semantically leans 
> much more heavily on the ABI versioning concept that we won’t otherwise need.

Yeah, the main downside I can think of with Chris’s approach is that for 
developers publishing source-only packages, version number ranges are probably 
overkill. I believe Jordan had a similar objection at some point in our 
internal discussions. However, treating @inlinable as shorthand for 
@available(inlinable) might be sufficient.


> 
> And the Tony-style spelling of @abiPublic should _clearly_ be 
> “internal(external)” for its amazingly oxymoronic yet accurate spelling.

If oxymoronic spelling discourages abuse of these features, I’m all for it ;-)

Slava

> 
>   — Greg
> 
>> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>>>  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
>>> 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/0193-cross-module-inlining-and-specialization.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?
>> 
>> I'm working on a performance sensitive library and we're sometimes bitten 
>> quite hard by not being able to cross-module inline & specialise. Therefore, 
>> it's thrilling to see that you're working in this area.
>> 
>> However, I have to admit that I believe this language feature will most 
>> likely be grossly abused. 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.
>> 
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> see above.
>> 
>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> to back up the 'swift' claim, cross-module inlining & specialisation is 
>> absolutely necessary. However this should also be achievable with a 'I don't 
>> need a stable ABI for this product' mode in the compiler :).
>> 
>> 
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>> 
>> 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.
>> 
>>  

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

[Slava Pestov via swift-evolution]

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!

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.

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.

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.

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]

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] Preserving non-mutability of methods of an existential or generic object

[Slava Pestov via swift-evolution]

Hi Hooman,

Since the protocol P is not class-bounded, the requirement can be witnessed by 
a protocol extension method which re-assigns ‘self’:

protocol Initable {
  init()
}

extension P where Self : Initable {
  mutating func f(_ x: Int) -> Int {
self = Self()
return x
  }
}

class C : P, Initable {
  required init() {}
}

Now imagine you could do this,

let x: P & AnyObject

x.f(12)

This would be invalid because ‘x’ is a let binding but the requirement ‘f’ is 
witnessed by the protocol extension method, which performs a mutating access of 
‘self’.

Slava

> On Dec 21, 2017, at 6:01 PM, Hooman Mehr via swift-evolution 
>  wrote:
> 
> The title is confusing, let me clarify by example:
> 
> We have this protocol with a mutating method:
> 
> protocol P { mutating func f(_ x: Int) -> Int }
> 
> And a conforming class (which has to conform with a non-mutating method):
> 
> class C: P { func f(_ x: Int) -> Int { return x } }
> 
> An instance of this class can be used with a let constant:
> 
> let c = C()
> c.f(1) // OK
>  
> If we make it an existential object conforming to P, the immutability of the 
> method will be erased:
> 
> let c: AnyObject & P = C()
> c.f(1) // Cannot use mutating member on immutable value: 'c' is a 'let' 
> constant
> 
> A generic context has the same issue:
> 
> func f(_ arg: T)-> Int { return arg.f(1) } // Cannot use 
> mutating member on immutable value: ‘arg' is a 'let' constant
> 
> My question: 
> 
> Is it too much work to preserve method non-mutability in in these cases?
> 
> The workaround I am using is this:
> 
> protocol Q: class, P { func f(_ x: Int) -> Int } // 'Refine' it to be 
> non-mutating.
> extension C: Q {}
> 
> // Now these work:
> let c: Q = C()
> c.f(1) // OK
> func f(_ arg: T)-> Int { return arg.f(1) } // OK
> 
> This workaround creates a lot of duplication and is hard to maintain. It is 
> not something that I do often, but when I do, it is pretty annoying. 
> 
> Supplemental questions:
> 
> Have you guys ever ran into this?
> Is there already a bug tracking this? 
> 
> 
> ___
> 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] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

[Stephen Celis via swift-evolution]

-1

It took awhile to catch up. I understand the motivation but don't agree with 
the solution. The suggested proposal adds language complexity that can 
hopefully be solved in other ways.

In catching up I related to Howard Lovatt's response. Jordan responded:

> On Dec 20, 2017, at 2:33 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I find it interesting that you call this the "unsafe" case. From my point of 
> view , it is very much in line with Swift's 
> current design to have the default be "force clients to consider all 
> possibilities" (like Optional), as well as "let library authors decide what a 
> client should be able to rely on" (like 'open').

I don't understand this. Optional is exhaustive. What you're describing is more 
like Swift error handling, which is quite different and much more cumbersome in 
use.

> This is an interesting point that I probably should have expanded more in the 
> "comparison with other languages" section. Swift has protocols too, and you 
> can build most of the features of enums with protocols. (Set aside the 
> inferior pattern-matching for now; that's something we could add to Swift.) 
> This is currently much more heavyweight than enums, but let's roll with it.
> 
> Next we have to deal with C enums, which can have "private cases" or 
> newly-added cases. Okay, maybe those get imported as structs instead, like 
> NS_OPTIONS. That's not too bad, is it?
> 
> Now we're back in a place where 'enum' always means "exhaustive". That's 
> good, right? Except…now we have a kind of type where the recommendation will 
> be "don't use these in your library's public API; they'll be stuck that way 
> forever", a trap waiting for library authors. That's a problem C has with 
> structs, and it's something we don't want to bring into Swift. Making a 
> library necessarily requires more care than making an app, but we don't want 
> there to be techniques that only make sense within a module, and are 
> discouraged when writing a library.
> 
> So we can implement this world in Swift. I just don't think it'll be a better 
> one. When someone makes a library, the default should be safe for them. That 
> means that they reserve the ability to add cases, and also to make the enum 
> "exhaustive" in the future if it turns out that's the right thing to do.
> 
> (You're free to continue to disagree with me on this; thanks for getting me 
> to write it out.)


I don't think the default third-party library case mirrors Foundation and UIKit 
(and authors that provide libraries like that must take more care in general 
and don't require extra language sugar that benefits just them). There are 
plenty of library authors whose default case is: when you upgrade to use our 
latest version, you need to consider all added cases, as it's source-breaking. 
I think this is far more common than the well-kempt releases Apple shepherds 
through each year.

I don't think we should lose our primitive type that always requires exhaustive 
switching, and I don't see the need to overcomplicate the language when we 
already have at-hand solutions (like extensible structs). If we're worried 
about library authors falling into the trap of misusing enums, we should 
provide a better mechanism for declaring raw-representable (or similar) 
entities, via something like NS_RAW_REPRESENTABLE, compiler magic, and/or a 
hygienic macro system.

I'd also like to point out that the current state of Swift development requires 
frameworks separate from the app:

1. If you want to import code into a playground. Playgrounds are a celebrated 
form of code demonstration, but app executable code cannot run in a playground. 
It needs to be extracted to a framework first.

2. SPM executables cannot run tests or have test targets. Testable SPM code 
needs to be extracted to a framework. If you want to test your code, it needs 
to be in a framework.

Both cases above affect app developers that aren't necessarily in the library 
biz. It's not great if the default for them is enums that suddenly become 
non-exhaustive.

Stephen

___
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

[Charlie Monroe via swift-evolution]

> On Dec 21, 2017, at 8:17 PM, Jordan Rose  wrote:
> 
> 
> 
>> On Dec 20, 2017, at 12:54, Charlie Monroe > > wrote:
>> 
>> I think that the main confusion here stems from the word library as we are 
>> addressing something that can be divided further (and this is IMHO as many 
>> macOS/iOS devs see it):
>> 
>> - libraries that come with the OS - here, it absolutely makes sense to make 
>> the enums non-exhaustive as the apps are linked against these libraries and 
>> the user installs a binary that will load these at launch and they are not 
>> bundled with the app - the developer can't control future OS releases and he 
>> wants the app to run on a future OS release.
>> - libraries that are bundled with the app - be it PM, CocoaPods or something 
>> else - you typically update your dependencies once in a while and they 
>> change. And you want to be notified by the compiler about possible changes - 
>> extended enums, in this case. Because let's be honest - if your app has a 
>> dozen dependencies and you come to the app after a year of no development, 
>> Swift 5 came along during that period, you want to update these libraries to 
>> Swift-5-compatible versions. And no one has the time to go through all 
>> change logs - even if they were kept up-to-date and thorough, which I can't 
>> say that I've seen in many instances.
>> 
>> I know that this is a limited view from the perspective of an app developer 
>> and that potentially, e.g. on Linux, there may be libraries written in Swift 
>> that you may want to install via package managers and depend on them once 
>> the ABI is stable, but the choice to make them non-exhaustive by default is 
>> not in line with everything else in Swift - everything else is generally 
>> closed by default - public (-> final in other modules), no access modified 
>> (-> internal), ...
>> 
>> For me, it's a -1 as it is now. I'd prefer exhaustive-by-default, 
>> ObjC/C-import non-exhaustive by default (the way ObjC classes are open by 
>> default vs. public). When it comes to the switch statement, there definitely 
>> needs to be an option to make an exhaustive switch over all 
>> compile-time-known values with a warning shall a new one be added. Without 
>> that, the code will become incredibly prone to errors and hard to maintain.
> 
> This does bring up another option, which is to differentiate Apple-provided 
> libraries (and in general, libraries with binary compatibility concerns, i.e. 
> libraries that may be different at run-time from what you compiled against) 
> from bundled / built-from-source libraries. Slava and I have been very leery 
> of this because it fragments the language into dialects, and has the 
> potential to confuse people when they try to write code that behaves like an 
> Apple framework, but I suppose it is an option.

I wouldn't differentiate, I would just try to think which should be the 
default. Which is more common? Which will be the more common scenario? I would 
dare say that vast majority (currently) falls under b) - and in these cases, it 
makes more sense to make the enum exhaustive by default.

> 
> Jordan
> 
> 
>> 
>>> On Dec 20, 2017, at 9:35 PM, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On 20. Dec 2017, at 19:54, Jordan Rose > wrote:
 
 
 
> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
> > wrote:
> 
> 
> 
>> On 19. Dec 2017, at 23:58, 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
>>  
>> +1,
>>  it needs to happen (and ASAP, since it _will_ introduce source-breaking 
>> changes one way or the other).
> 
> I think non-exhaustive is the correct default. However, does this not 
> mean that, by default, enums will be boxed because the receiver doesn’t 
> know their potential size?
 
 It's not always boxing, but yes, there will be more indirection if the 
 compiler can't see the contents of the enum. (More on that below.)
 
 
> That would mean that the best transition path for multi-module Apps would 
> be to make your enums @exhaustive, rather than adding “default” 
> statements (which is unfortunate, because I imagine when this change 
> hits, the way you’ll notice will be complaints about missing “default” 

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

[Erica Sadun via swift-evolution]

> On Dec 19, 2017, at 4:42 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> 
> 
>> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> I disagree. Let’s not reopen what is settled. “Compact” can be a noun just 
>> as “map” and “filter” can; as long as there are no in-place variants, there 
>> can be no ambiguity.
>> On Tue, Dec 19, 2017 at 17:11 Brent Royal-Gordon via swift-evolution 
>> > wrote:
>>> On Dec 19, 2017, at 8:56 AM, John McCall >> > wrote:
>>> 
>>> Therefore, SE-0187 is accepted, with the revision that the new name be 
>>> Sequence.compactMap(_:), and with the agreement that we will add 
>>> Sequence.compact() when it is possible to do so.
>> 
>> 
>> I like `compact` as the basis for the name, but I hope the core team will 
>> consider whether the eventual nil-removal method should be called 
>> `compacting()`, and whether therefore this method should be called 
>> `compactingMap(_:)`. Prior art on the name `compact()` does exist, but I 
>> don't think it's strong enough to justify deviating from the API Guidelines.
>> 
>> I don't think we need a full review on this tiny issue; five minutes of the 
>> core team's time should more than suffice.
> 
> I agree with Brent. IMO we're firmly outside the domain of established 
> terms-of-art here (Ruby notwithstanding). 

I lean slightly towards "but they already have been through this", but given 
that the core term is "compact" and it is secondary to map, then I think 
`mapCompacting` is superior: 

* It mirrors the process better (apply function, then decide whether to include 
or exclude the result)
* It prefers `compacting` as Brent points out, supporting the Swift API 
Guidelines
* It uses the term of art `map` consistently with this preferred term.
* It places the two names closer together in autocomplete

-- E, hiding the bikeshed paintbrush behind her back___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Chris Lattner via swift-evolution]

To answer your meta question, no, we don’t want to add lots of operators.  We 
are willing to add them if they are very strongly motivated, but prefer not to 
if there are other ways to solve the problem.

In this case it sounds like:

   x = optionalValue ?? x

Is a reasonable substitute.

-Chris

> On Dec 21, 2017, at 10:38 AM, Benoit Pereira da silva via swift-evolution 
>  wrote:
> 
> Stephen,
> 
> You are right the proposal #0024 is very close.
> But in fact the logic is inverted.  
> 
> When using «=? » the right item is optional.
> a =? b assigns « b »  to « a »  only if « b »  is defined.
> So if an optional is defined =? will not erase its value.
> 
> But my real questions was…
> Do you have such operators that you really use very often?
> Should we incorporate bunches of new operators / micro-syntactic sugar?
> Is swift evolution the good place to discuss such question?
> 
> I don’t want to pollute your mail boxes.
> 
> Best regards,
> 
> B
> 
>> Le 21 déc. 2017 à 19:12, Stephen Celis  a écrit :
>> 
>> Such an operator was proposed here: 
>> https://github.com/apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5547d0e0925/proposals/0024-optional-value-setter.md
>> 
>> It was ultimately rejected: 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/43.html
>> 
>> Stephen
>> 
>>> On Dec 21, 2017, at 11:44 AM, Benoit Pereira da silva via swift-evolution 
>>>  wrote:
>>> 
>>> Dear all,
>>> 
>>> That’s not ambitious but i think worth be explored.
>>> 
>>> What do you think for example of this Infix operator?
>>> « =? »  allows to express optional assignments  in a very concise way.
>>> 
>>> 
>>> // The `=? operator allows simplify optional assignements :
>>> //  `a = b ?? a` can be written : `a =? b`
>>> infix operator =?: AssignmentPrecedence
>>> 
>>> public func =? ( left:inout T?, right: T? ){
>>> left = right ?? left
>>> }
>>> 
>>> public func =? ( left:inout T, right: T? ){
>>> left = right ?? left
>>> }
>>> 
>>> 
>>> Do you have such operators that you really use very often?
>>> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> 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] Preserving non-mutability of methods of an existential or generic object

[Hooman Mehr via swift-evolution]

The title is confusing, let me clarify by example:

We have this protocol with a mutating method:

protocol P { mutating func f(_ x: Int) -> Int }

And a conforming class (which has to conform with a non-mutating method):

class C: P { func f(_ x: Int) -> Int { return x } }

An instance of this class can be used with a let constant:

let c = C()
c.f(1) // OK
 
If we make it an existential object conforming to P, the immutability of the 
method will be erased:

let c: AnyObject & P = C()
c.f(1) // Cannot use mutating member on immutable value: 'c' is a 'let' constant

A generic context has the same issue:

func f(_ arg: T)-> Int { return arg.f(1) } // Cannot use 
mutating member on immutable value: ‘arg' is a 'let' constant

My question: 

Is it too much work to preserve method non-mutability in in these cases?

The workaround I am using is this:

protocol Q: class, P { func f(_ x: Int) -> Int } // 'Refine' it to be 
non-mutating.
extension C: Q {}

// Now these work:
let c: Q = C()
c.f(1) // OK
func f(_ arg: T)-> Int { return arg.f(1) } // OK

This workaround creates a lot of duplication and is hard to maintain. It is not 
something that I do often, but when I do, it is pretty annoying. 

Supplemental questions:

Have you guys ever ran into this?
Is there already a bug tracking this? 


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

Re: [swift-evolution] Enums and Source Compatibility

[Kevin Nattinger via swift-evolution]

> On Oct 2, 2017, at 2:10 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> I don't think I have anything to say on this topic that I haven't already 
> said:
> 
> - Switching exhaustively over non-exhaustive enums is uncommon.

[Citation Needed]
As I pointed out in my email in the review thread, there are a significant 
number of enums in Apple's own frameworks that are commonly switched over 
exhaustively.

Additionally, uncommon or not, when this does come up, it's an enormous issue. 
Big enough that "it's uncommon" isn't sufficient justification for ignoring it.

> - It's more important for a library to build without errors when its 
> dependencies change than it is to get an error. (This doesn't apply to 
> warnings, though.)

Not sure I agree with this. In fact I think if anything it's more important for 
libraries than clients. Especially in the case of a new enum value it should 
support but doesn't.

> - Untestable code is dangerous, so having a language feature inherently for 
> untestable code seems bad.

A `default` case in the same situation is just as untestable, as you even point 
out in the proposal. Why do you keep using this as an argument against `future` 
but not `default`?

> 
> None of that negates your points; it just affects the weighting of whether or 
> not 'future' or 'switch!' is worth it. However, I've added a link to your 
> email in the proposal proper so that the Core Team and wider review audience 
> have a chance to decide differently.
> 
> Jordan
> 
> 
>> On Oct 2, 2017, at 08:25, Vladimir.S via swift-evolution 
>> > wrote:
>> 
>> 
>> Sorry to bother, but I still can't understand how the proposed change 
>> *without* a 'future' case in switch will change our life and what would be 
>> our steps to support our code and to not make our code buggy.
>> If I misunderstand something - sorry, please point me on this and I hope 
>> this also help some one like me to understand the subject better.
>> 
>> For example. I use OAuth2 framework, built by Carthage. Did add the 
>> OAuth2.framework to my project.
>> 
>> Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in my 
>> code where I switch on each case of such error instance to do my best with 
>> error: generate detailed description for user, other additional steps 
>> depending on error.
>> 
>> Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No.
>> Will new cases be added to that enum in future: Most likely Yes.
>> Do I need to switch on each case in my code? Yes.
>> Can I currently rely on compiler to keep my error processing in sync with 
>> error cases defined in framework? Yes.
>> Can new cases appear in *run-time* of my app: NO, framework in embedded.
>> Will I be able to rely on compiler after the proposed change? No?!
>> What should I do to keep my switch in sync with OAuth2Error cases after each 
>> update of OAuth2 library(framework)? Manually check if new cases are added?! 
>> Configure lint/other tools to help me with this?!
>> 
>> What I, as a developer, as a consumer of framework, need - is a way to 
>> exhaustively switch on *some* external non-exhaustive enums *at the moment 
>> of compilation*. And we can accomplish this only(AFAICT) with 'future' case 
>> in 'switch'.
>> In case we'll have 'future' case my life will not be *worse* for this 
>> project : I'll add it to my switch and still can receive help from compiler 
>> to keep switch exhaustive.
>> 
>> I don't support the opinion that we can't introduce 'future' case because of 
>> we can't test it:
>> 
>> 1. Not being able to keep my switch exhaustive when I need this, and so not 
>> being able to provide users of my app with best experience - IMO is worse.
>> 2. In my particular example, 'future' case will be *never* called, if I 
>> understand correctly.
>> 3. If switch on non-exhaustive enum is exhaustive by fact, we can't test the 
>> 'default' branch also. So, 'future' is in same position here with 'default'
>> 4. I believe if we'll decide we need 'future' case - we can suggest a way to 
>> call code in that case during the test process.
>> 
>> Seems like for embedded frameworks we should apply the same rules(regarding 
>> enums) as for sources, as we compile the app with concrete binary of 
>> framework and there just can't be new cases in enums. No?
>> 
>> Thank you for your time.
>> Vladimir.
>> 
>> On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote:
 On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution 
  
 >> 
 wrote:
 
 I don’t see how it’s impractical. Quite a lot about how the library should 
 be optimally compiled and used depends on what you plan to do with it. If 
 it’s going to be installed somewhere private and you can guarantee clients 
 

Re: [swift-evolution] Enums and Source Compatibility

[Andrew Bennett via swift-evolution]

Can you go into more detail about why the core team didn't like this?

public enum HomeworkExcuse {
  case eatenByPet
  case thoughtItWasDueNextWeek
  default // NEW}


To me this is very close to an ideal solution, it fixes ABI concerns, it
has sensible defaults. If it was changed a little bit:

public enum HomeworkExcuse {
  case eatenByPet
  case thoughtItWasDueNextWeek
  fallback unknown // NEW}


Then I believe you would be able to have an exhaustive switch like this:

switch thing {
  case eatenByPet: break
  case thoughtItWasDueNextWeek: break
  case unknown: break}


Which would *still allow compile-time errors if new cases are introduced*,
while providing a concise way to show something is not exhaustible.

This would also *support existing enums with "unknown" equivalent cases*
would be able to explicitly label those fields as fallback without needing
to make large code changes.

I see no reason why you shouldn't be able to use ".unknown", which *should
still allow this to be testable*.

Thanks,
Andrew

On Tue, Oct 3, 2017 at 8:10 AM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> I don't think I have anything to say on this topic that I haven't already
> said:
>
> - Switching exhaustively over non-exhaustive enums is uncommon.
> - It's more important for a library to build without errors when its
> dependencies change than it is to get an error. (This doesn't apply to
> warnings, though.)
> - Untestable code is dangerous, so having a language feature inherently
> for untestable code seems bad.
>
> None of that negates your points; it just affects the weighting of whether
> or not 'future' or 'switch!' is worth it. However, I've added a link to
> your email in the proposal proper so that the Core Team and wider review
> audience have a chance to decide differently.
>
> Jordan
>
>
> On Oct 2, 2017, at 08:25, Vladimir.S via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Sorry to bother, but I still can't understand how the proposed change
> *without* a 'future' case in switch will change our life and what would be
> our steps to support our code and to not make our code buggy.
> If I misunderstand something - sorry, please point me on this and I hope
> this also help some one like me to understand the subject better.
>
> For example. I use OAuth2 framework, built by Carthage. Did add the
> OAuth2.framework to my project.
>
> Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in
> my code where I switch on each case of such error instance to do my best
> with error: generate detailed description for user, other additional steps
> depending on error.
>
> Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No.
> Will new cases be added to that enum in future: Most likely Yes.
> Do I need to switch on each case in my code? Yes.
> Can I currently rely on compiler to keep my error processing in sync with
> error cases defined in framework? Yes.
> Can new cases appear in *run-time* of my app: NO, framework in embedded.
> Will I be able to rely on compiler after the proposed change? No?!
> What should I do to keep my switch in sync with OAuth2Error cases after
> each update of OAuth2 library(framework)? Manually check if new cases are
> added?! Configure lint/other tools to help me with this?!
>
> What I, as a developer, as a consumer of framework, need - is a way to
> exhaustively switch on *some* external non-exhaustive enums *at the moment
> of compilation*. And we can accomplish this only(AFAICT) with 'future' case
> in 'switch'.
> In case we'll have 'future' case my life will not be *worse* for this
> project : I'll add it to my switch and still can receive help from compiler
> to keep switch exhaustive.
>
> I don't support the opinion that we can't introduce 'future' case because
> of we can't test it:
>
> 1. Not being able to keep my switch exhaustive when I need this, and so
> not being able to provide users of my app with best experience - IMO is
> worse.
> 2. In my particular example, 'future' case will be *never* called, if I
> understand correctly.
> 3. If switch on non-exhaustive enum is exhaustive by fact, we can't test
> the 'default' branch also. So, 'future' is in same position here with
> 'default'
> 4. I believe if we'll decide we need 'future' case - we can suggest a way
> to call code in that case during the test process.
>
> Seems like for embedded frameworks we should apply the same
> rules(regarding enums) as for sources, as we compile the app with concrete
> binary of framework and there just can't be new cases in enums. No?
>
> Thank you for your time.
> Vladimir.
>
> On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote:
>
> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution <
> swift-evolution@swift.org  >> wrote:
>
> I don’t see how it’s impractical. Quite a lot about how the library should
> be optimally compiled and used depends on 

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

[Rod Brown via swift-evolution]

Thanks for this response, John.

I think you’re right. This would be very helpful. It a) helps those who are 
source compiling with their app, and b) avoids fragmenting the language because 
it would be a core understanding of the code you are compiling, rather than 
creating a new “variant” of Swift for the binary compatible framework vs client 
code.

- Rod

> On 22 Dec 2017, at 6:26 am, John McCall via swift-evolution 
>  wrote:
> 
> 
>>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> 
>>> 
 On Dec 20, 2017, at 12:35, Karl Wagner  wrote:
 
 
 
> On 20. Dec 2017, at 19:54, Jordan Rose  wrote:
> 
> 
> 
>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>> On 19. Dec 2017, at 23:58, 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
> +1, it needs to happen (and ASAP, since it _will_ introduce 
> source-breaking changes one way or the other).
> 
> I think non-exhaustive is the correct default. However, does this not 
> mean that, by default, enums will be boxed because the receiver doesn’t 
> know their potential size?
 
 It's not always boxing, but yes, there will be more indirection if the 
 compiler can't see the contents of the enum. (More on that below.)
 
 
> That would mean that the best transition path for multi-module Apps would 
> be to make your enums @exhaustive, rather than adding “default” 
> statements (which is unfortunate, because I imagine when this change 
> hits, the way you’ll notice will be complaints about missing “default” 
> statements).
 
 Yep, that's going to be the recommendation. The current minimal-for-review 
 implementation does not do this but I'd like to figure out how to improve 
 that; at the very least it might be a sensible thing to do in the migrator.
 
> 
> I do have some thoughts about how we could ease the transition (for this 
> and other resilience-related changes), but it’s best to leave that to a 
> separate discussion.
> 
> The one thing I’m still not overly fond of is the name - I would like us 
> to keep the set of resilience/optimisation related keywords to a minimum. 
> “exhaustive” for enums feels an awful lot like “fixed_contents” for 
> structs - couldn’t we come up with a single name which could be used for 
> both? I don’t think anybody’s going to want to use “exhaustive” for 
> structs.
 
 The core team was very focused on this too, but I contend that 
 "exhaustive" is not about optimization and really isn't even about 
 "resilience" (i.e. the ability to evolve a library's API while preserving 
 binary compatibility). It's a semantic feature of an enum, much like 
 'open' or 'final' is for classes, and it affects what a client can or 
 can't do with an enum. For libaries compiled from source, it won't affect 
 performance at all—the compiler still knows the full set of cases in the 
 current version of the library even if the programmer is forced to 
 consider future versions.
 
 I'm working on the fixed-contents proposal now, though it won't be ready 
 for a while, and the same thing applies there: for structs compiled from 
 source, the compiler can still do all the same optimizations. It's only 
 when the library has binary compatibility concerns that we need to use 
 extra indirection, and then "fixed-contents" becomes important. (As 
 currently designed, it doesn't affect what clients can do with the struct 
 at all.) This means that I don't expect a "normal" package author to write 
 "fixed-contents" at all (however it ends up being spelled), whereas 
 "exhaustive" is a fairly normal thing to consider whenever you make an 
 enum public.
 
 I hope that convinces you that "fixed-contents" and "exhaustive" don't 
 need to have the same name. I don't think anyone loves the particular name 
 "exhaustive", but as you see in the "Alternatives considered" we didn't 
 manage to come up with anything significantly better. If reviewers all 
 prefer something else we'd consider changing it.
 
 Thanks for responding!
 Jordan
 
>>> 
>>> When you say “libraries compiled from source”, what do you mean?
>> 
>> - Other targets in your project
>> - Source packages built through SwiftPM / CocoaPods / Carthage / other
>> 
>> And I was being imprecise with the terminology, but also

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

[David Owens via swift-evolution]

I very much agree with the high-level of the proposal. The concept definitely 
needs to exist. However, I feel that the options presented do so in a 
non-intuitive way.

There are two concepts here: closed and open listing of values that make up a 
set of possible options to be used. I think of this much like struct vs. class 
in terms having to determine conceptually which is the right approach for the 
problem you are solving. As such, I feel that this is a significant enough 
difference between the concepts that it warrants a declarative difference via a 
keyword, not just some annotation.

Further, for me personally, putting conditional differences on access level has 
always been a very annoying and frustrating experience in Swift, and this adds 
to that. Using a keyword to distinguish helps with that.

I don’t know the best spelling for, but I’d want something like this:

enumset GregorianWeekday
{ 
case monday // ISO 8601 says weeks start on Monday
case tuesday
case wednesday
case thursday
case friday
case saturday
case sunday
}

That’s the exhaustive list, no others can be added. Access level does not 
matter.

enum Emotions
{
case happy
case sad
case angry
}

This is a non-exhaustive list. Others can be added via extensions. Access level 
does not matter.

-David

> 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?
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> 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-0193 - Cross-module inlining and specialization

[Paul Cantrell via swift-evolution]

Thanks for the answers, Slava. More inline below.

> On Dec 21, 2017, at 12:30 AM, Slava Pestov  wrote:
> 
> Hi Paul,
> 
> Thanks for reviewing the proposal!
> 
>> On Dec 20, 2017, at 9:21 PM, Paul Cantrell > > wrote:
>> 
>> A concern: how would a library author reason about, and check for bugs in, 
>> the combinatorial explosion of old and new implementations that could exist 
>> simultaneously with this feature in use?
> 
> I don’t have a simple answer to this unfortunately, other than the author 
> being really careful, perhaps keeping around build artifacts that were 
> compiled against older versions of the library and testing those.
> 
>> That last paragraph gives a relatively trivial example, but the implications 
>> are daunting! If I understand correctly, anything in a library that uses any 
>> @inlinable or @abiPublic code must be prepared to deal with every possible 
>> combination of every past published implementation of that code. And that 
>> “every possible combination” is not per function, but per…call site?
>> 
>> Suppose we have this:
>> 
>> // Module A
>> 
>> @inlineable func bar() { ... }
>> 
>> // Module B
>> 
>> @inlineable func foo() {
>> if whatever {
>> bar(0)  // compiler decides to inline this...
>> } else {
>> bar(1)  // ...but not this, for whatever reason
>> }
>> }
>> 
>> // Module C
>> 
>> func baz() {
>> foo()
>> }
>> 
>> …and suppose B was compiled against A v1.0 but C was compiled against A 
>> v2.0. Then, if I’m following, it’s possible for bar(0) to use the 1.0 
>> implementation but bar(1) to use the 2.0 impl. Do I have that right? It 
>> seems to be what the hash value example is getting at.
> 
> That is correct. Another example is if module A publishes an inlinable 
> function, and module B and C depend on A, but B and C were compiled with 
> different versions of A. Then a fourth module D that depends on B and C might 
> see two different published versions of this function.

I am … horrified and intrigued! I suppose C++ headers have always had exactly 
the same problems, but never having been the maintainer of a C++ library, I 
never had to worry about it.

More follow-up “huh” questions:

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

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?

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.

> 
>> Or is this not as dangerous as I’m imagining it to be?
> 
> It *is* pretty dangerous, which is why I hope this feature is used 
> judiciously by third-party binary frameworks. With source frameworks that are 
> built together with an app and always recompiled, this is less of a concern.

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.

Per this and my questions above, a proposal:

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 version mixing as an error, and require 
an explicit statement of compatibility intent for each piece of inlinable code 
to opt in to the danger zone of mixed versions.

Then inlinable code could opt in by specifying some sort of past and future 
compatibility contract, e.g. “inline-compatible with version 2.x of this 
module,” perhaps using syntax along the lines of the @available stuff Chris 
proposed elsewhere in this thread. IOW, my #3 just above would be necessary for 
the compiler to allow any version 

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

[Rex Fenley via swift-evolution]

I agree with everything said by Brent Royal-Gordon, however a -1 without
the addition of a `future` case or something similar.

   -

   What is your evaluation of the proposal?

-1, this solution solves a real problem but introduces a very significant
drawback. It should include a solution that preserves exhaustive pattern
matching for the user.

   -

   Is the problem being addressed significant enough to warrant a change to
   Swift?

Yes, absolutely.

   -

   Does this proposal fit well with the feel and direction of Swift?

Feels like 1 step forward and 1 step back. Solves a real problem and
introduces a real new one.

   -

   If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?

Rust settled on exhaustive as the default case, signaling the importance of
preserving exhaustive pattern matching. I've run into bugs in Objective-C,
where there is no exhaustive pattern matching, and that's been a pain -
since enums are more powerful in Swift the consequences may be worse.

   -

   How much effort did you put into your review? A glance, a quick reading,
   or an in-depth study?

I've actively participated in previous discussions on the topic, and read
the proposal top-to-bottom for this review. I leverage enums and exhaustive
pattern matching significantly in my own code.

> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution <
swift-evolution@swift.org> wrote:
>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution <
swift-evolution@swift.org> wrote:
>>
>>  • What is your evaluation of the proposal?
>
> I am pleased with the broad strokes of this design. I have quibbles with
three areas:
>
> 1. The `@exhaustive` attribute may be confusing because the term doesn't
suggest versioning. My best alternative suggestion is `@frozen`, which
matches existing programming terminology: something that has been frozen
will not be changed in the future.
>
> 2. I think we need some kind of `future` keyword in `switch` statements.
Even though a nonexhaustive enum may gain additional cases in the future,
it's still useful for the compiler to diagnose that you forgot *known*
cases.
>
> You say that "switches over non-exhaustive enums should be uncommon", and
this is true for many—perhaps most—non-exhaustive enums, but there is still
a large class of non-exhaustive enums which need to be switched over. These
are the ones I called "category 2" in my previous email in this thread.
`SKPaymentTransactionState` is the example I previously used; others might
include `Stream.Status` (if not exhaustive), `CLAuthorizationStatus`,
`EKParticipantType`, `PKPaymentMethodType`, and `MKMapType`. Each of these
could plausibly have more cases added; each has a good reason why you might
switch over cases (such as display in a user interface); and each ought to
be promptly updated when a new OS version introduces new cases. Without
compiler assistance, those updates won't happen.
>
> If we plan to add private cases in a future version of Swift, `future`
may not be the best keyword. `unknown`, `invalid` (or `case #invalid`),
etc. may be better.
>
> 3. I am very skeptical of treating all enums as exhaustive if imported by
`@testable import`. The only reason I can see not to do this is that
forcing you to provide `default` might hide tests that need to be updated
for new enum cases—but this is the exact problem that `future` is trying to
solve. By contrast, treating them as non-exhaustive forces you to actually
notice when an enum is published as nonexhaustive and consider whether
that's the right approach.
>
> None of these are showstoppers if left unaddressed, but I think the
design would be better if we fixed them.
>
>>  • Is the problem being addressed significant enough to warrant a
change to Swift?
>
> Yes. I have no idea how Swift programs currently behave when a future
framework version adds a case, but I can't imagine they do anything good.
>
>>  • Does this proposal fit well with the feel and direction of Swift?
>
> Yes, with the exception of conflating `default` and `future`, which
removes useful correctness checks.
>
>>  • If you have used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
>
> I've experienced bugs in Objective-C caused by the compiler not knowing
an enum might have additional, unknown cases. Debugging them sucked.
>
>>  • How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
>
> I've participated in multiple rounds of discussion on this topic, and
read the proposal top-to-bottom for this review.
>
> --
> Brent Royal-Gordon
> Architechies
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 

Rex Fenley  |  IOS DEVELOPER

Remind.com  |  BLOG 

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

[Matthew Johnson via swift-evolution]

> On Dec 21, 2017, at 2:17 PM, John McCall  wrote:
> 
> 
>> On Dec 21, 2017, at 3:10 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Dec 21, 2017, at 2:06 PM, John McCall >> > wrote:
>>> 
>>> 
 On Dec 21, 2017, at 2:41 PM, Matthew Johnson > wrote:
 
 
> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution 
> > wrote:
> 
>> 
>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On Dec 20, 2017, at 12:35, Karl Wagner >> > wrote:
>>> 
>>> 
>>> 
 On 20. Dec 2017, at 19:54, Jordan Rose > wrote:
 
 
 
> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
> > wrote:
> 
> 
> 
>> On 19. Dec 2017, at 23:58, 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
>>  
>> +1,
>>  it needs to happen (and ASAP, since it _will_ introduce 
>> source-breaking changes one way or the other).
> 
> I think non-exhaustive is the correct default. However, does this not 
> mean that, by default, enums will be boxed because the receiver 
> doesn’t know their potential size?
 
 It's not always boxing, but yes, there will be more indirection if the 
 compiler can't see the contents of the enum. (More on that below.)
 
 
> That would mean that the best transition path for multi-module Apps 
> would be to make your enums @exhaustive, rather than adding “default” 
> statements (which is unfortunate, because I imagine when this change 
> hits, the way you’ll notice will be complaints about missing 
> “default” statements).
 
 Yep, that's going to be the recommendation. The current 
 minimal-for-review implementation does not do this but I'd like to 
 figure out how to improve that; at the very least it might be a 
 sensible thing to do in the migrator.
 
> 
> I do have some thoughts about how we could ease the transition (for 
> this and other resilience-related changes), but it’s best to leave 
> that to a separate discussion.
> 
> The one thing I’m still not overly fond of is the name - I would like 
> us to keep the set of resilience/optimisation related keywords to a 
> minimum. “exhaustive” for enums feels an awful lot like 
> “fixed_contents” for structs - couldn’t we come up with a single name 
> which could be used for both? I don’t think anybody’s going to want 
> to use “exhaustive” for structs.
 
 The core team was very focused on this too, but I contend that 
 "exhaustive" is not about optimization and really isn't even about 
 "resilience" (i.e. the ability to evolve a library's API while 
 preserving binary compatibility). It's a semantic feature of an enum, 
 much like 'open' or 'final' is for classes, and it affects what a 
 client can or can't do with an enum. For libaries compiled from 
 source, it won't affect performance at all—the compiler still knows 
 the full set of cases in the current version of the library even if 
 the programmer is forced to consider future versions.
 
 I'm working on the fixed-contents proposal now, though it won't be 
 ready for a while, and the same thing applies there: for structs 
 compiled from source, the compiler can still do all the same 
 optimizations. It's only when the library has binary compatibility 
 concerns that we need to use extra indirection, and then 
 "fixed-contents" becomes important. (As currently designed, it doesn't 
 affect what clients can do with the struct at all.) This means that I 
 don't expect a "normal" package author to write "fixed-contents" at 
 all (however it ends up being spelled), whereas "exhaustive" is 

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

[John McCall via swift-evolution]

> On Dec 21, 2017, at 3:10 PM, Matthew Johnson  wrote:
> 
> 
>> On Dec 21, 2017, at 2:06 PM, John McCall > > wrote:
>> 
>> 
>>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson >> > wrote:
>>> 
>>> 
 On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution 
 > wrote:
 
> 
> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
> > wrote:
> 
> 
> 
>> On Dec 20, 2017, at 12:35, Karl Wagner > > wrote:
>> 
>> 
>> 
>>> On 20. Dec 2017, at 19:54, Jordan Rose >> > wrote:
>>> 
>>> 
>>> 
 On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
 > wrote:
 
 
 
> On 19. Dec 2017, at 23:58, 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
>  
> +1,
>  it needs to happen (and ASAP, since it _will_ introduce 
> source-breaking changes one way or the other).
 
 I think non-exhaustive is the correct default. However, does this not 
 mean that, by default, enums will be boxed because the receiver 
 doesn’t know their potential size?
>>> 
>>> It's not always boxing, but yes, there will be more indirection if the 
>>> compiler can't see the contents of the enum. (More on that below.)
>>> 
>>> 
 That would mean that the best transition path for multi-module Apps 
 would be to make your enums @exhaustive, rather than adding “default” 
 statements (which is unfortunate, because I imagine when this change 
 hits, the way you’ll notice will be complaints about missing “default” 
 statements).
>>> 
>>> Yep, that's going to be the recommendation. The current 
>>> minimal-for-review implementation does not do this but I'd like to 
>>> figure out how to improve that; at the very least it might be a 
>>> sensible thing to do in the migrator.
>>> 
 
 I do have some thoughts about how we could ease the transition (for 
 this and other resilience-related changes), but it’s best to leave 
 that to a separate discussion.
 
 The one thing I’m still not overly fond of is the name - I would like 
 us to keep the set of resilience/optimisation related keywords to a 
 minimum. “exhaustive” for enums feels an awful lot like 
 “fixed_contents” for structs - couldn’t we come up with a single name 
 which could be used for both? I don’t think anybody’s going to want to 
 use “exhaustive” for structs.
>>> 
>>> The core team was very focused on this too, but I contend that 
>>> "exhaustive" is not about optimization and really isn't even about 
>>> "resilience" (i.e. the ability to evolve a library's API while 
>>> preserving binary compatibility). It's a semantic feature of an enum, 
>>> much like 'open' or 'final' is for classes, and it affects what a 
>>> client can or can't do with an enum. For libaries compiled from source, 
>>> it won't affect performance at all—the compiler still knows the full 
>>> set of cases in the current version of the library even if the 
>>> programmer is forced to consider future versions.
>>> 
>>> I'm working on the fixed-contents proposal now, though it won't be 
>>> ready for a while, and the same thing applies there: for structs 
>>> compiled from source, the compiler can still do all the same 
>>> optimizations. It's only when the library has binary compatibility 
>>> concerns that we need to use extra indirection, and then 
>>> "fixed-contents" becomes important. (As currently designed, it doesn't 
>>> affect what clients can do with the struct at all.) This means that I 
>>> don't expect a "normal" package author to write "fixed-contents" at all 
>>> (however it ends up being spelled), whereas "exhaustive" is a fairly 
>>> normal thing to consider whenever you make an enum public.
>>> 
>>> I hope that convinces you that "fixed-contents" and "exhaustive" don't 
>>> need to have the same name. I don't 

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

[Nevin Brackett-Rozinsky via swift-evolution]

Making enums non-exhaustive solves a problem for authors of precompiled
frameworks which apps can dynamically link against. These libraries need to
preserve binary compatibility, in the sense that apps should continue to
work with newer versions of the library.

Now, that creates a problem for app developers, wherein the compiler no
longer informs them when their switch statements don’t cover all known enum
cases. This can be solved by introducing “future” for switch statements,
which acts like “default” but will warn if it is provably reachable.

Perhaps the most common scenario, however, is developers who write
multi-module apps. Such apps could include modules with the same author,
modules included as source, and even precompiled binary modules. As long as
these are all bundled with the app, they cannot possibly change out from
under it at runtime, so binary-compatibility is not a concern.

I think it is important that any solution to the problems of dynamically
linked libraries should not adversely impact authors of multi-module apps.

It sounds like John McCall has an approach to handle this with version
locking of dependencies.

Another possibility is to say that public enums are non-exhaustive by
default if the module is built with resilience enabled, but if resilience
is not enabled then enums are exhaustive.

Alternatively, we could introduce a concept of “the entire thing I am
building, including all its statically-linked modules”, and let enums be
exhaustive within that domain while still defaulting to non-exhaustive
outside it.

I am glad to see vigorous debate and brainstorming on this thread, and I am
confident that we will find a good solution.

Nevin



On Thu, Dec 21, 2017 at 2:26 PM, John McCall via swift-evolution <
swift-evolution@swift.org> wrote:

>
> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On Dec 20, 2017, at 12:35, Karl Wagner  wrote:
>
>
>
> On 20. Dec 2017, at 19:54, Jordan Rose  wrote:
>
>
>
> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
>
> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution <
> swift-evolution@swift.org> 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
>
> +1, it needs to happen (and ASAP, since it _will_ introduce
> source-breaking changes one way or the other).
>
> I think non-exhaustive is the correct default. However, does this not mean
> that, by default, enums will be boxed because the receiver doesn’t know
> their potential size?
>
>
> It's not always boxing, but yes, there will be more indirection if the
> *compiler* can't see the contents of the enum. (More on that below.)
>
>
> That would mean that the best transition path for multi-module Apps would
> be to make your enums @exhaustive, rather than adding “default” statements
> (which is unfortunate, because I imagine when this change hits, the way
> you’ll notice will be complaints about missing “default” statements).
>
>
> Yep, that's going to be the recommendation. The current minimal-for-review
> implementation does not do this but I'd like to figure out how to improve
> that; at the very least it might be a sensible thing to do in the migrator.
>
>
> I do have some thoughts about how we could ease the transition (for this
> and other resilience-related changes), but it’s best to leave that to a
> separate discussion.
>
> The one thing I’m still not overly fond of is the name - I would like us
> to keep the set of resilience/optimisation related keywords to a minimum.
> “exhaustive” for enums feels an awful lot like “fixed_contents” for structs
> - couldn’t we come up with a single name which could be used for both? I
> don’t think anybody’s going to want to use “exhaustive” for structs.
>
>
> The core team was very focused on this too, but I contend that
> "exhaustive" is not about optimization and really isn't even about
> "resilience" (i.e. the ability to evolve a library's API while preserving
> binary compatibility). It's a semantic feature of an enum, much like 'open'
> or 'final' is for classes, and it affects what a client can or can't do
> with an enum. For libaries compiled from source, it won't affect
> performance at all—the *compiler* still knows the full set of cases in the
>  *current* version of the library even if the programmer is forced to
> consider future versions.
>
> I'm working on the fixed-contents proposal now, though it won't be ready
> for a while, and the same thing applies there: for structs compiled from
> source, the compiler can still do all the same optimizations. It's only
> when the library has binary compatibility concerns that we need to use
> extra indirection, and then "fixed-contents" becomes 

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

[Matthew Johnson via swift-evolution]

> On Dec 21, 2017, at 2:06 PM, John McCall  wrote:
> 
> 
>> On Dec 21, 2017, at 2:41 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution 
>>> > wrote:
>>> 
 
 On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
 > wrote:
 
 
 
> On Dec 20, 2017, at 12:35, Karl Wagner  > wrote:
> 
> 
> 
>> On 20. Dec 2017, at 19:54, Jordan Rose > > wrote:
>> 
>> 
>> 
>>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On 19. Dec 2017, at 23:58, 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
  
 +1,
  it needs to happen (and ASAP, since it _will_ introduce 
 source-breaking changes one way or the other).
>>> 
>>> I think non-exhaustive is the correct default. However, does this not 
>>> mean that, by default, enums will be boxed because the receiver doesn’t 
>>> know their potential size?
>> 
>> It's not always boxing, but yes, there will be more indirection if the 
>> compiler can't see the contents of the enum. (More on that below.)
>> 
>> 
>>> That would mean that the best transition path for multi-module Apps 
>>> would be to make your enums @exhaustive, rather than adding “default” 
>>> statements (which is unfortunate, because I imagine when this change 
>>> hits, the way you’ll notice will be complaints about missing “default” 
>>> statements).
>> 
>> Yep, that's going to be the recommendation. The current 
>> minimal-for-review implementation does not do this but I'd like to 
>> figure out how to improve that; at the very least it might be a sensible 
>> thing to do in the migrator.
>> 
>>> 
>>> I do have some thoughts about how we could ease the transition (for 
>>> this and other resilience-related changes), but it’s best to leave that 
>>> to a separate discussion.
>>> 
>>> The one thing I’m still not overly fond of is the name - I would like 
>>> us to keep the set of resilience/optimisation related keywords to a 
>>> minimum. “exhaustive” for enums feels an awful lot like 
>>> “fixed_contents” for structs - couldn’t we come up with a single name 
>>> which could be used for both? I don’t think anybody’s going to want to 
>>> use “exhaustive” for structs.
>> 
>> The core team was very focused on this too, but I contend that 
>> "exhaustive" is not about optimization and really isn't even about 
>> "resilience" (i.e. the ability to evolve a library's API while 
>> preserving binary compatibility). It's a semantic feature of an enum, 
>> much like 'open' or 'final' is for classes, and it affects what a client 
>> can or can't do with an enum. For libaries compiled from source, it 
>> won't affect performance at all—the compiler still knows the full set of 
>> cases in the current version of the library even if the programmer is 
>> forced to consider future versions.
>> 
>> I'm working on the fixed-contents proposal now, though it won't be ready 
>> for a while, and the same thing applies there: for structs compiled from 
>> source, the compiler can still do all the same optimizations. It's only 
>> when the library has binary compatibility concerns that we need to use 
>> extra indirection, and then "fixed-contents" becomes important. (As 
>> currently designed, it doesn't affect what clients can do with the 
>> struct at all.) This means that I don't expect a "normal" package author 
>> to write "fixed-contents" at all (however it ends up being spelled), 
>> whereas "exhaustive" is a fairly normal thing to consider whenever you 
>> make an enum public.
>> 
>> I hope that convinces you that "fixed-contents" and "exhaustive" don't 
>> need to have the same name. I don't think anyone loves the particular 
>> name "exhaustive", but as you see in the "Alternatives considered" we 
>> didn't manage to come up with anything significantly better. If 
>> reviewers all prefer 

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

[John McCall via swift-evolution]

> On Dec 21, 2017, at 2:41 PM, Matthew Johnson  wrote:
> 
> 
>> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On Dec 20, 2017, at 12:35, Karl Wagner > wrote:
 
 
 
> On 20. Dec 2017, at 19:54, Jordan Rose  > wrote:
> 
> 
> 
>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On 19. Dec 2017, at 23:58, 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
>>>  
>>> +1,
>>>  it needs to happen (and ASAP, since it _will_ introduce 
>>> source-breaking changes one way or the other).
>> 
>> I think non-exhaustive is the correct default. However, does this not 
>> mean that, by default, enums will be boxed because the receiver doesn’t 
>> know their potential size?
> 
> It's not always boxing, but yes, there will be more indirection if the 
> compiler can't see the contents of the enum. (More on that below.)
> 
> 
>> That would mean that the best transition path for multi-module Apps 
>> would be to make your enums @exhaustive, rather than adding “default” 
>> statements (which is unfortunate, because I imagine when this change 
>> hits, the way you’ll notice will be complaints about missing “default” 
>> statements).
> 
> Yep, that's going to be the recommendation. The current 
> minimal-for-review implementation does not do this but I'd like to figure 
> out how to improve that; at the very least it might be a sensible thing 
> to do in the migrator.
> 
>> 
>> I do have some thoughts about how we could ease the transition (for this 
>> and other resilience-related changes), but it’s best to leave that to a 
>> separate discussion.
>> 
>> The one thing I’m still not overly fond of is the name - I would like us 
>> to keep the set of resilience/optimisation related keywords to a 
>> minimum. “exhaustive” for enums feels an awful lot like “fixed_contents” 
>> for structs - couldn’t we come up with a single name which could be used 
>> for both? I don’t think anybody’s going to want to use “exhaustive” for 
>> structs.
> 
> The core team was very focused on this too, but I contend that 
> "exhaustive" is not about optimization and really isn't even about 
> "resilience" (i.e. the ability to evolve a library's API while preserving 
> binary compatibility). It's a semantic feature of an enum, much like 
> 'open' or 'final' is for classes, and it affects what a client can or 
> can't do with an enum. For libaries compiled from source, it won't affect 
> performance at all—the compiler still knows the full set of cases in the 
> current version of the library even if the programmer is forced to 
> consider future versions.
> 
> I'm working on the fixed-contents proposal now, though it won't be ready 
> for a while, and the same thing applies there: for structs compiled from 
> source, the compiler can still do all the same optimizations. It's only 
> when the library has binary compatibility concerns that we need to use 
> extra indirection, and then "fixed-contents" becomes important. (As 
> currently designed, it doesn't affect what clients can do with the struct 
> at all.) This means that I don't expect a "normal" package author to 
> write "fixed-contents" at all (however it ends up being spelled), whereas 
> "exhaustive" is a fairly normal thing to consider whenever you make an 
> enum public.
> 
> I hope that convinces you that "fixed-contents" and "exhaustive" don't 
> need to have the same name. I don't think anyone loves the particular 
> name "exhaustive", but as you see in the "Alternatives considered" we 
> didn't manage to come up with anything significantly better. If reviewers 
> all prefer something else we'd consider changing it.
> 
> Thanks for responding!
> Jordan
> 
 
 When you say “libraries compiled from source”, what do you mean?
>>> 
>>> - Other targets in your project

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

[Goffredo Marocchi via swift-evolution]

+1 kind of eye opening looking at it from that angle :/.

Sent from my iPhone

> On 21 Dec 2017, at 18:02, Dave DeLong via swift-evolution 
>  wrote:
> 
> I realized further why we should not implement this proposal: It forces the 
> problem of binary compatibility on the app developer, when experience has 
> shown us that problem is better handled by the libraries.
> 
> Binary Compatibility
> 
> “Binary compatibility” is the notion that, even if the libraries you link 
> against change, your app will still behave as it did when it was first 
> compiled. For Swift apps these days, we don’t really have this problem, 
> *yet*. We do have the problem of “binary compatibility” with Apple-provided 
> frameworks, but those are all written in Objective-C, and so the question of 
> “Swift” binary compatibility is still up-in-the-air.
> 
> Post-ABI stability, we still won’t have much issue with swift binary 
> compatibility on Apple platforms, because there isn’t a mechanism to ship a 
> framework to your users independently of an app update. So from the app POV, 
> none of this will be a problem for Apple platform developers.
> 
> It will be a problem for non-Apple platform developers. As a simple example, 
> let’s say I write a web app in Swift, and deploy it to a server that has some 
> built-in Swift-on-the-server libraries. Here, my Swift app is decoupled from 
> the libraries, and either one can update independently of each other. If the 
> server owner decides to update from Swift 6 to Swift 6.1, that’s cool. But my 
> web app should continue to run and behave *as if* the server were still 
> running Swift 6, because it has not been re-compiled to use Swift 6.1 
> features.
> 
> This is the situation today on Apple platforms. Every app deployed to an 
> Apple device includes a little piece of information in the executable file 
> indicating which SDK was used to compile the app. At runtime, the system 
> frameworks read this value and then alter their behavior accordingly. This is 
> why apps written against the iOS 9 SDK continue to work on iOS 11 devices; 
> UIKit and friends are altering their behavior to provide iOS 9 semantics. 
> 
> This is “binary compatibility”: the binary (your app) continues to be 
> compatible with the dynamically linked frameworks present on the system, even 
> though those frameworks may change.
> 
> When you have a setup where the frameworks do NOT provide binary 
> compatibility, you end up in DLL Hell [1]. This is the same frustrating 
> scenario when you’re in when you’re doing stuff with homebrew and find that 
> this package you want has multiple dependencies, but these dependencies want 
> different versions of the same library. [2]
> 
> Exhaustive Enums
> 
> All of the discussion around exhaustive enums has been from the point-of-view 
> of “what should the behavior be when the libraries change”. Thinking back, 
> I’m actually surprised this is a question at all, because Apple answered this 
> *years* ago: THE BEHAVIOR SHOULD REMAIN UNCHANGED. It is up to the library 
> authors to ensure that they’re doing what the compiled-and-unchanging 
> application is expecting them to do.
> 
> This discussion around exhaustive enums is basically saying “can we force the 
> developers to deal with binary incompatibility?”. We absolutely should not. 
> There are far more app developers than library developers, and it would be a 
> massively wasteful expenditure of engineering effort to force each and every 
> app developer to deal with binary incompatibility, when the library can do it 
> for them. That is the entire *purpose* of having libraries: abstract out a 
> problem so that I, as an app developer, don’t have to spend the effort to do 
> it myself.
> 
> Where We Should Go
> 
> Instead of forcing developers to deal with incompatible libraries, we should 
> be discussing ways to make binary compatibility easier to implement in 
> libraries.
> 
> One of the major problems I struggled with as a UIKit engineer was the 
> presence of huge numbers of “if … else” checks in the code to deal with 
> binary compatibility. It exploded the cyclomatic complexity of the classes 
> and was a major source of technical debt that I struggled to not add to.
> 
> 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.
> 
> But forcing developers to deal with binary incompatibility is a solution 
> we’ve long known to be a bad one. We should not perpetuate that sin in Swift.
> 
> Dave
> 
> [1]: https://en.wikipedia.org/wiki/DLL_Hell
> [2]: https://en.wikipedia.org/wiki/Dependency_hell
> 
> 
>> On Dec 20, 2017, at 10:23 AM, Dave DeLong via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution 
>>> 

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

[Ash Furrow via swift-evolution]

Okay, thanks Jordan. I appreciate your perspective, and I admit that the 
proposal is technically compelling. My criticism was from a place of respect 
and admiration, and while I may have missed the deeper technical points of the 
proposal, I’ll still caution about how this change will be received by the 
Swift developer community. Proposals like this one could benefit from a 
plain-language explanation that this (as Joe Groff explained on twitter) fixes 
a bug. Maybe even a few more before and after examples? That would help the 
proposal get ahead of any negative reaction.

Ash

-- 
Ash Furrow
https://ashfurrow.com/

On December 21, 2017 at 1:55:40 PM, Jordan Rose (jordan_r...@apple.com) wrote:

Thanks for your response, Ash. Comments inline.


On Dec 20, 2017, at 11:49, Ash Furrow via swift-evolution 
 wrote:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md

What is your evaluation of the proposal?

-1.

Is the problem being addressed significant enough to warrant a change to Swift?

I’m afraid not.

>From my perspective as a Swift user, this change represents nontrivial 
>language churn without providing a solution to a problem I have. The proposal 
>doesn’t describe any benefits to me as an open source library maintainer or as 
>a Swift developer. With earnest respect, the motivation section reads like 
>“enums grow sometimes, but we like to exhaustively switch over them, so 
>wouldn’t it be cool if …”, which is only a theoretical motivation. It fails to 
>describe how and why this proposal would improve my Swift code or my 
>experience using Swift.

This appears to be a solution to a non-existing problem. I worry that making 
this change will alienate developers from Swift and I caution against accepting 
it.

I wish it were, but unfortunately it's a very real problem. Cases are added to 
Cocoa all the time, and currently it is undefined behavior if one of those 
cases makes it into a switch defined in Swift. ("undefined behavior" = "no 
guarantees of memory safety, type safety, or even which functions are going to 
get invoked in the rest of the function") This is a terrible state of affairs 
that we need to do something about, and "make it a deterministic trap" isn't a 
good enough answer.

We also already know that we have clients that want to add new cases to Swift 
enums without breaking source or binary compatibility: the Apple overlays. It's 
true that this is more of a "theoretical motivation" for source framework 
authors at this time.



Does this proposal fit well with the feel and direction of Swift?

It may have at one time point in time, but not now.

The chaotic churn of the language, the syntax, and the standard library is 
supposed to be behind us. We need to accept that things fell into place as they 
did, often in imperfect ways. We probably could correct all the imperfections, 
but when would we ever stop? Language churn has a cost. This proposal is 
something that I could definitely see being a part of Swift 2 or Swift 3, but 
we have already decided that enums are exhaustive. This change, and changes 
fundamental to the cognitive model Swift programmers already have of their 
tool, need to be heavily weighted against language churn

There's a difference between imperfections that mean something is a bit harder 
to use, or not named the right thing, and imperfections that lead to crashes or 
core capabilities not being expressible. Being able to add cases to enums is 
something Cocoa developers have relied on for years in Objective-C, and so it 
isn't really sensible to not have this feature in Swift. I definitely wish we 
could have gotten to it sooner.



If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

Scala’s match syntax bears a striking resemblance to Swift’s switch syntax; 
however, Scala does not require exhaustive cases. If the developer does not 
include a default case and none of the cases match the expression, an exception 
is thrown. Because of Swift’s error-handling model, I don’t know that this 
behaviour would be desirable either (though I will say it makes sense in Scala).

This is certainly an option; it's in the proposal under "Alternatives 
considered" as 'switch!' (causing a deterministic trap rather than an 
exception). That doesn't seem sufficient to deal with the realities of Cocoa, 
though.

Jordan



How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?

I read most of the proposal (okay I skimmed some of the nitty-gritty, but I 
read to the end of “Source compatibility”) as well as looked over the 
pre-review threads and skimmed GitHub pull request thread.

-- 
Ash Furrow
https://ashfurrow.com/

On December 19, 2017 at 5:58:14 PM, Ted Kremenek via swift-evolution 
(swift-evolution@swift.org) wrote:

The review of "SE 0192 - Non-Exhaustive Enums" 

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

[Matthew Johnson via swift-evolution]

> On Dec 21, 2017, at 1:26 PM, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On Dec 20, 2017, at 12:35, Karl Wagner >> > wrote:
>>> 
>>> 
>>> 
 On 20. Dec 2017, at 19:54, Jordan Rose > wrote:
 
 
 
> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
> > wrote:
> 
> 
> 
>> On 19. Dec 2017, at 23:58, 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
>>  
>> +1,
>>  it needs to happen (and ASAP, since it _will_ introduce source-breaking 
>> changes one way or the other).
> 
> I think non-exhaustive is the correct default. However, does this not 
> mean that, by default, enums will be boxed because the receiver doesn’t 
> know their potential size?
 
 It's not always boxing, but yes, there will be more indirection if the 
 compiler can't see the contents of the enum. (More on that below.)
 
 
> That would mean that the best transition path for multi-module Apps would 
> be to make your enums @exhaustive, rather than adding “default” 
> statements (which is unfortunate, because I imagine when this change 
> hits, the way you’ll notice will be complaints about missing “default” 
> statements).
 
 Yep, that's going to be the recommendation. The current minimal-for-review 
 implementation does not do this but I'd like to figure out how to improve 
 that; at the very least it might be a sensible thing to do in the migrator.
 
> 
> I do have some thoughts about how we could ease the transition (for this 
> and other resilience-related changes), but it’s best to leave that to a 
> separate discussion.
> 
> The one thing I’m still not overly fond of is the name - I would like us 
> to keep the set of resilience/optimisation related keywords to a minimum. 
> “exhaustive” for enums feels an awful lot like “fixed_contents” for 
> structs - couldn’t we come up with a single name which could be used for 
> both? I don’t think anybody’s going to want to use “exhaustive” for 
> structs.
 
 The core team was very focused on this too, but I contend that 
 "exhaustive" is not about optimization and really isn't even about 
 "resilience" (i.e. the ability to evolve a library's API while preserving 
 binary compatibility). It's a semantic feature of an enum, much like 
 'open' or 'final' is for classes, and it affects what a client can or 
 can't do with an enum. For libaries compiled from source, it won't affect 
 performance at all—the compiler still knows the full set of cases in the 
 current version of the library even if the programmer is forced to 
 consider future versions.
 
 I'm working on the fixed-contents proposal now, though it won't be ready 
 for a while, and the same thing applies there: for structs compiled from 
 source, the compiler can still do all the same optimizations. It's only 
 when the library has binary compatibility concerns that we need to use 
 extra indirection, and then "fixed-contents" becomes important. (As 
 currently designed, it doesn't affect what clients can do with the struct 
 at all.) This means that I don't expect a "normal" package author to write 
 "fixed-contents" at all (however it ends up being spelled), whereas 
 "exhaustive" is a fairly normal thing to consider whenever you make an 
 enum public.
 
 I hope that convinces you that "fixed-contents" and "exhaustive" don't 
 need to have the same name. I don't think anyone loves the particular name 
 "exhaustive", but as you see in the "Alternatives considered" we didn't 
 manage to come up with anything significantly better. If reviewers all 
 prefer something else we'd consider changing it.
 
 Thanks for responding!
 Jordan
 
>>> 
>>> When you say “libraries compiled from source”, what do you mean?
>> 
>> - Other targets in your project
>> - Source packages built through SwiftPM / CocoaPods / Carthage / other
>> 
>> And I was being imprecise with the terminology, but also
>> 
>> - Libraries built by someone else but designed to be embedded into an app, 
>> so 

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

[John McCall via swift-evolution]

> On Dec 21, 2017, at 2:03 PM, Jordan Rose via swift-evolution 
>  wrote:
> 
> 
> 
>> On Dec 20, 2017, at 12:35, Karl Wagner > > wrote:
>> 
>> 
>> 
>>> On 20. Dec 2017, at 19:54, Jordan Rose >> > wrote:
>>> 
>>> 
>>> 
 On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
 > wrote:
 
 
 
> On 19. Dec 2017, at 23:58, 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
>  
> +1,
>  it needs to happen (and ASAP, since it _will_ introduce source-breaking 
> changes one way or the other).
 
 I think non-exhaustive is the correct default. However, does this not mean 
 that, by default, enums will be boxed because the receiver doesn’t know 
 their potential size?
>>> 
>>> It's not always boxing, but yes, there will be more indirection if the 
>>> compiler can't see the contents of the enum. (More on that below.)
>>> 
>>> 
 That would mean that the best transition path for multi-module Apps would 
 be to make your enums @exhaustive, rather than adding “default” statements 
 (which is unfortunate, because I imagine when this change hits, the way 
 you’ll notice will be complaints about missing “default” statements).
>>> 
>>> Yep, that's going to be the recommendation. The current minimal-for-review 
>>> implementation does not do this but I'd like to figure out how to improve 
>>> that; at the very least it might be a sensible thing to do in the migrator.
>>> 
 
 I do have some thoughts about how we could ease the transition (for this 
 and other resilience-related changes), but it’s best to leave that to a 
 separate discussion.
 
 The one thing I’m still not overly fond of is the name - I would like us 
 to keep the set of resilience/optimisation related keywords to a minimum. 
 “exhaustive” for enums feels an awful lot like “fixed_contents” for 
 structs - couldn’t we come up with a single name which could be used for 
 both? I don’t think anybody’s going to want to use “exhaustive” for 
 structs.
>>> 
>>> The core team was very focused on this too, but I contend that "exhaustive" 
>>> is not about optimization and really isn't even about "resilience" (i.e. 
>>> the ability to evolve a library's API while preserving binary 
>>> compatibility). It's a semantic feature of an enum, much like 'open' or 
>>> 'final' is for classes, and it affects what a client can or can't do with 
>>> an enum. For libaries compiled from source, it won't affect performance at 
>>> all—the compiler still knows the full set of cases in the current version 
>>> of the library even if the programmer is forced to consider future versions.
>>> 
>>> I'm working on the fixed-contents proposal now, though it won't be ready 
>>> for a while, and the same thing applies there: for structs compiled from 
>>> source, the compiler can still do all the same optimizations. It's only 
>>> when the library has binary compatibility concerns that we need to use 
>>> extra indirection, and then "fixed-contents" becomes important. (As 
>>> currently designed, it doesn't affect what clients can do with the struct 
>>> at all.) This means that I don't expect a "normal" package author to write 
>>> "fixed-contents" at all (however it ends up being spelled), whereas 
>>> "exhaustive" is a fairly normal thing to consider whenever you make an enum 
>>> public.
>>> 
>>> I hope that convinces you that "fixed-contents" and "exhaustive" don't need 
>>> to have the same name. I don't think anyone loves the particular name 
>>> "exhaustive", but as you see in the "Alternatives considered" we didn't 
>>> manage to come up with anything significantly better. If reviewers all 
>>> prefer something else we'd consider changing it.
>>> 
>>> Thanks for responding!
>>> Jordan
>>> 
>> 
>> When you say “libraries compiled from source”, what do you mean?
> 
> - Other targets in your project
> - Source packages built through SwiftPM / CocoaPods / Carthage / other
> 
> And I was being imprecise with the terminology, but also
> 
> - Libraries built by someone else but designed to be embedded into an app, so 
> that there's no chance of a different version showing up at run-time.
> 
>> 
>> As for whether its a resilience feature: actually it is completely a 
>> resilience feature. The effects on switching are only side-effects; really 
>> what “exhaustive” or 

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

[Kelvin Ma via swift-evolution]

On Thu, Dec 21, 2017 at 12:26 AM, Slava Pestov  wrote:

> Thanks for the review, Kelvin.
>
> On Dec 20, 2017, at 8:52 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> it makes sense to have @abiPublic on private and fileprivate declarations
> too and i hope this gets added, because private and fileprivate are tools
> for code organization and maintenance,, the compiler with wmo doesn’t care
> about private vs internal. but @abiPublic private is bound to cause
> confusion and it just reads funny.
>
>
> From an implementation standpoint, it would be a simple change to allow
> @abiPublic on private and fileprivate declarations. However, I think that
> introduce some confusion. Recall that the mangling of private symbols
> includes the source file name. This would now be part of your framework’s
> ABI. If you moved the @abiPublic function to another source file, or rename
> the source file, you will break ABI.
>
> Another approach would be to change the mangling so that @abiPublic
> private symbols are mangled like internal symbols, with a module name and
> no source file name. This makes for a simpler ABI. However this also has a
> downside, because now if you define two @abiPublic private functions in
> different files that have the same mangling, you will get a linker error
> and not a nice compiler diagnostic.
>
> Note that nothing in this proposal precludes @abiPublic from being applied
> to private and fileprivate symbols though. If we figure out a nice solution
> to the above problems, we could generalize @abiPublic without any issues.
>
> Slava
>
>
i understand that but i also feel like that’s a completely solvable problem
if someone put in some effort to look into it. right now i think
fileprivate is the only problematic keyword with this since i think
changing the name of a private type makes a lot more sense that it would
break abi than renaming a file would. but it’s also the least used so
that’s a plus.
___
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

[Jordan Rose via swift-evolution]

> On Dec 20, 2017, at 12:54, Charlie Monroe  wrote:
> 
> I think that the main confusion here stems from the word library as we are 
> addressing something that can be divided further (and this is IMHO as many 
> macOS/iOS devs see it):
> 
> - libraries that come with the OS - here, it absolutely makes sense to make 
> the enums non-exhaustive as the apps are linked against these libraries and 
> the user installs a binary that will load these at launch and they are not 
> bundled with the app - the developer can't control future OS releases and he 
> wants the app to run on a future OS release.
> - libraries that are bundled with the app - be it PM, CocoaPods or something 
> else - you typically update your dependencies once in a while and they 
> change. And you want to be notified by the compiler about possible changes - 
> extended enums, in this case. Because let's be honest - if your app has a 
> dozen dependencies and you come to the app after a year of no development, 
> Swift 5 came along during that period, you want to update these libraries to 
> Swift-5-compatible versions. And no one has the time to go through all change 
> logs - even if they were kept up-to-date and thorough, which I can't say that 
> I've seen in many instances.
> 
> I know that this is a limited view from the perspective of an app developer 
> and that potentially, e.g. on Linux, there may be libraries written in Swift 
> that you may want to install via package managers and depend on them once the 
> ABI is stable, but the choice to make them non-exhaustive by default is not 
> in line with everything else in Swift - everything else is generally closed 
> by default - public (-> final in other modules), no access modified (-> 
> internal), ...
> 
> For me, it's a -1 as it is now. I'd prefer exhaustive-by-default, 
> ObjC/C-import non-exhaustive by default (the way ObjC classes are open by 
> default vs. public). When it comes to the switch statement, there definitely 
> needs to be an option to make an exhaustive switch over all 
> compile-time-known values with a warning shall a new one be added. Without 
> that, the code will become incredibly prone to errors and hard to maintain.

This does bring up another option, which is to differentiate Apple-provided 
libraries (and in general, libraries with binary compatibility concerns, i.e. 
libraries that may be different at run-time from what you compiled against) 
from bundled / built-from-source libraries. Slava and I have been very leery of 
this because it fragments the language into dialects, and has the potential to 
confuse people when they try to write code that behaves like an Apple 
framework, but I suppose it is an option.

Jordan


> 
>> On Dec 20, 2017, at 9:35 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On 20. Dec 2017, at 19:54, Jordan Rose >> > wrote:
>>> 
>>> 
>>> 
 On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
 > wrote:
 
 
 
> On 19. Dec 2017, at 23:58, 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
>  
> +1,
>  it needs to happen (and ASAP, since it _will_ introduce source-breaking 
> changes one way or the other).
 
 I think non-exhaustive is the correct default. However, does this not mean 
 that, by default, enums will be boxed because the receiver doesn’t know 
 their potential size?
>>> 
>>> It's not always boxing, but yes, there will be more indirection if the 
>>> compiler can't see the contents of the enum. (More on that below.)
>>> 
>>> 
 That would mean that the best transition path for multi-module Apps would 
 be to make your enums @exhaustive, rather than adding “default” statements 
 (which is unfortunate, because I imagine when this change hits, the way 
 you’ll notice will be complaints about missing “default” statements).
>>> 
>>> Yep, that's going to be the recommendation. The current minimal-for-review 
>>> implementation does not do this but I'd like to figure out how to improve 
>>> that; at the very least it might be a sensible thing to do in the migrator.
>>> 
 
 I do have some thoughts about how we could ease the transition (for this 
 and other resilience-related changes), but it’s best to leave that to a 
 separate discussion.
 
 The one thing I’m still not overly fond of is the name - I 

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Kelvin Ma via swift-evolution]

possibly off-topic but what i would really find useful is some way of
expressing guard/if assignment instead of initialization so that

let geomSource:UnsafeMutableBufferPointer?
if let geometryFile:String = geometryFile
{
guard let _geomSource:UnsafeMutableBufferPointer =
Shader.openTextFile(Shader.posixPath(geometryFile))
else
{
return nil
}

geomSource = _geomSource
}

could be rewritten as

let geomSource:UnsafeMutableBufferPointer?
if let geometryFile:String = geometryFile
{
guard geomSource:UnsafeMutableBufferPointer =
Shader.openTextFile(Shader.posixPath(geometryFile))
else
{
return nil
}
}

On Thu, Dec 21, 2017 at 1:00 PM, Stephen Celis via swift-evolution <
swift-evolution@swift.org> wrote:

> Ah, sorry, I misread! For readability I think I'd still favor something
> like:
>
> if let b = b {
>   dict[a] = b
> }
>
> And I think some the arguments made in #0024 may still apply here, though
> feel free to discuss!
>
> Stephen
>
> On Dec 21, 2017, at 1:37 PM, Benoit Pereira da silva  wrote:
>
> Stephen,
>
> You are right the proposal #0024 is very close.
> But in fact the logic is inverted.
>
> When using «=? » the right item is optional.
> a =? b assigns « b »  to « a »  only if « b »  is defined.
> So if an optional is defined =? will not erase its value.
>
> But my real questions was…
> Do you have such operators that you really use very often?
> Should we incorporate bunches of new operators / micro-syntactic sugar?
> Is swift evolution the good place to discuss such question?
>
> I don’t want to pollute your mail boxes.
>
> Best regards,
>
> B
>
> Le 21 déc. 2017 à 19:12, Stephen Celis  a écrit :
>
> Such an operator was proposed here: https://github.com/
> apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5
> 547d0e0925/proposals/0024-optional-value-setter.md
>
> It was ultimately rejected: https://lists.swift.
> org/pipermail/swift-evolution-announce/2016-February/43.html
>
> Stephen
>
> On Dec 21, 2017, at 11:44 AM, Benoit Pereira da silva via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Dear all,
>
> That’s not ambitious but i think worth be explored.
>
> What do you think for example of this Infix operator?
> « =? »  allows to express optional assignments  in a very concise way.
>
>
> // The `=? operator allows simplify optional assignements :
> //  `a = b ?? a` can be written : `a =? b`
> infix operator =?: AssignmentPrecedence
>
> public func =? ( left:inout T?, right: T? ){
> left = right ?? left
> }
>
> public func =? ( left:inout T, right: T? ){
> left = right ?? left
> }
>
>
> Do you have such operators that you really use very often?
>
>
> *Benoit Pereira da Silva*
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com
>
> 
>
>
>
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of
> this information for any purpose is prohibited without agreement of the
> sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou
> usage des informations contenues dans ce message sont interdits sans
> agrément préalable de l'expéditeur.
>
>
>
> ___
> 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

[Jordan Rose via swift-evolution]

> On Dec 20, 2017, at 12:52, Colin Barrett  wrote:
> 
> 
>> On Dec 20, 2017, at 1:36 PM, Jordan Rose > > wrote:
>> 
>> Thanks for the links, Colin. I think neither of these approaches are 
>> appropriate for Swift, largely for the same reason: they can't be used to 
>> define a library's API. Polymorphic variants are ad-hoc union types (much 
>> like tuples are ad-hoc structs) which—apart from having other problems in 
>> Swift previously discussed on this list—means that you can't add new cases 
>> to them. That is, any API which takes `(red(r: Int) | green(g: Int) | 
>> blue(b: Int))` today can't add `alpha(a: Int)` in the future, because that 
>> would change the type.
>  
> It would change the type yes, but not in a binary incompatible way. Imagine 
> this for the OS version, using OCaml pseudocode
> 
> type VERS = [> `10_0 | `10_1 | … | `10_13 ]
> 
> Then, next year, you’d change VERS to be,
> 
> type VERS = [> `10_0 | `10_1 | … | `10_13 | `10_14 ]
> 
> Any code that dealt with a VERS would still work, as it had to handle that it 
> could contain other tags.

Sorry, I had this worked out in my head but then didn't put it into the email 
correctly! The sticking point is that Swift allows overloads by type, which 
means that argument types have to go into the mangled name of the function. 
(Another way to think of this is to say "to uniquely identify a function across 
releases, you must know its argument and return types as well as its full 
name".) That means that we can't just add a new case into the type, because it 
would change the function's type.

Okay, but what if VERS were an actual new type rather than just a typealias? 
Well, then you have a non-exhaustive enum.

(David Owens brought up on Twitter today that it could be a different kind of 
declaration rather than 'enum'. My response 
 was that that could 
work, but you end up in a worse case where (a) the two declarations are 
equivalent when they're not public, and (b) it's still easy to use the wrong 
one, especially going from Swift 1-4 habits.)


> 
>> ML-style exceptions have the opposite problem; they are completely 
>> unconstrained and so a client can add new "cases" without the library author 
>> being prepared. (Swift's error-handling model in general behaves a lot like 
>> this, except it doesn't get ML's knowledge of which errors might be thrown.)
> 
> Yes, I was imagining that this would be for something with an OCaml type like 
> [> ]  or TOP, which I don’t believe is a thing? My OCaml-fu is quite weak.
> 
>> I'd sum this up by saying Swift is differing from ML and from most other 
>> languages because it is solving a different problem. Swift is designed such 
>> that the compiler does not require whole-program knowledge to produce a 
>> correct, working, type-safe program. It will use any cross-module knowledge 
>> it can for optimization purposes, but the language semantics do not depend 
>> on it. And this is critical, as you note, for libraries with binary 
>> compatibility concerns.
> 
> That is… not different from ML? ML’s modules have precisely this properly, do 
> they not? Or am I misunderstanding what you’re saying here.

ML modules provide separation of concerns, but as far as I know they can't 
actually be swapped out at runtime, and if someone were to do this they 
wouldn't be allowed to add a new variant to an existing datatype.


> Thanks for the reply, it’s appreciated! Hope you’re well in California, 
> envious of your weather trudging thru the snow here in NYC.

Happy holidays, Colin, and everyone else on the list. :-)

Jordan


___
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

[Jordan Rose via swift-evolution]

Thanks for your comments, Jon. Responses inline.

> On Dec 20, 2017, at 12:46, Jonathan Hull  wrote:
> 
> 
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>> > wrote:
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
> Strong -1 as is.
> 
> I think I would support having an explicit ‘futureCase’ which is different 
> from ‘default’.  Requiring default is asking for bugs.  With a separate 
> ‘futureCase’, we would still get a compile-time error when all of the current 
> cases aren’t handled.  Note that ‘ futureCase’ is also different than 
> ‘default’ in that it wouldn’t have to go at the bottom.  It would only be 
> triggered when the value isn’t one of the values which was known at compile 
> time.  We should also bike shed the name of ‘futureCase’ to come up with 
> something that might allow us to make other types of extendable enums….  
> Maybe something like ‘unknownCase’ or ‘unexpectedCase’.
> 
> As for the issue of testing, we could add (later) a universally unexpected 
> case that non-exhaustive enums can be set to for testing. I am not convinced 
> that this is actually a big enough issue to warrant that though. Forcing 
> ‘default’ is a much larger real-world problem, IMO (and this use of ‘default’ 
> is just as untestable).

Both of these are discussed in "Alternatives considered", and they have flaws 
that led me to leave them out of the proposal. Do you have any ideas on how to 
improve on that?

> 
> I also dislike the name @exhaustive because I think it will cause confusion 
> (i.e. “Of course my Enum is exhaustive”).  I think we should just have @fixed 
> for both enums and structs. The word fixed has the connotation that it 
> shouldn’t change.

I don't think anybody loves "exhaustive", but using the same attribute for 
enums and structs isn't really appropriate, as discussed in my response to Karl 
yesterday 
.
 I'm not opposed to a better name if we can gravitate towards one, though.

Jordan



> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> 
> Yes, I think the problem is significant, but this is not the correct solution.
>> Does this proposal fit well with the feel and direction of Swift?
>> 
> Not quite.  While I think ABI safety is Swifty, I feel like this design 
> actually encourages a lack of safety in other areas.  Much better to 
> explicitly deal with the issue of added/future cases in code than to hide it 
> with ‘default’.
> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> 
> I have used Enums in several languages, but Swift is the only one which has 
> required exhaustive enums… I have a hard time going back to languages which 
> don’t have it now.
> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> 
> Thoroughly read proposal, casually followed the original discussion.
> 
> Thanks,
> Jon
> 
> 

___
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

[Greg Titus via swift-evolution]

I come from a perspective similar to Johannes, in that: for my work we are 
interested in the performance improvements of cross-module optimization and 
specialization but we regularly rebuild frameworks along with apps and 
explicitly don’t need ABI versioning. Unlike him, I’m not that concerned with 
littering attributes for inlinability around, but for our purposes the original 
proposed spelling of @inlinable/@abiPublic or even better, Tony’s proposed 
public(inlinable) makes for easier understanding when reading the code than 
Chris’s proposed @available() extensions, which semantically leans much more 
heavily on the ABI versioning concept that we won’t otherwise need.

And the Tony-style spelling of @abiPublic should _clearly_ be 
“internal(external)” for its amazingly oxymoronic yet accurate spelling.

— Greg

> On Dec 21, 2017, at 8:06 AM, Johannes Weiß via swift-evolution 
>  wrote:
> 
> 
>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>>  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
>> 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/0193-cross-module-inlining-and-specialization.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?
> 
> I'm working on a performance sensitive library and we're sometimes bitten 
> quite hard by not being able to cross-module inline & specialise. Therefore, 
> it's thrilling to see that you're working in this area.
> 
> However, I have to admit that I believe this language feature will most 
> likely be grossly abused. 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.
> 
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> see above.
> 
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> to back up the 'swift' claim, cross-module inlining & specialisation is 
> absolutely necessary. However this should also be achievable with a 'I don't 
> need a stable ABI for this product' mode in the compiler :).
> 
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> 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.
> 
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> read the proposal (and believe to understand it).
> 
> -- Johannes
> 
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 

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

[Jordan Rose via swift-evolution]

> On Dec 20, 2017, at 12:35, Karl Wagner  wrote:
> 
> 
> 
>> On 20. Dec 2017, at 19:54, Jordan Rose > > wrote:
>> 
>> 
>> 
>>> On Dec 20, 2017, at 05:36, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On 19. Dec 2017, at 23:58, 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
  
 +1,
  it needs to happen (and ASAP, since it _will_ introduce source-breaking 
 changes one way or the other).
>>> 
>>> I think non-exhaustive is the correct default. However, does this not mean 
>>> that, by default, enums will be boxed because the receiver doesn’t know 
>>> their potential size?
>> 
>> It's not always boxing, but yes, there will be more indirection if the 
>> compiler can't see the contents of the enum. (More on that below.)
>> 
>> 
>>> That would mean that the best transition path for multi-module Apps would 
>>> be to make your enums @exhaustive, rather than adding “default” statements 
>>> (which is unfortunate, because I imagine when this change hits, the way 
>>> you’ll notice will be complaints about missing “default” statements).
>> 
>> Yep, that's going to be the recommendation. The current minimal-for-review 
>> implementation does not do this but I'd like to figure out how to improve 
>> that; at the very least it might be a sensible thing to do in the migrator.
>> 
>>> 
>>> I do have some thoughts about how we could ease the transition (for this 
>>> and other resilience-related changes), but it’s best to leave that to a 
>>> separate discussion.
>>> 
>>> The one thing I’m still not overly fond of is the name - I would like us to 
>>> keep the set of resilience/optimisation related keywords to a minimum. 
>>> “exhaustive” for enums feels an awful lot like “fixed_contents” for structs 
>>> - couldn’t we come up with a single name which could be used for both? I 
>>> don’t think anybody’s going to want to use “exhaustive” for structs.
>> 
>> The core team was very focused on this too, but I contend that "exhaustive" 
>> is not about optimization and really isn't even about "resilience" (i.e. the 
>> ability to evolve a library's API while preserving binary compatibility). 
>> It's a semantic feature of an enum, much like 'open' or 'final' is for 
>> classes, and it affects what a client can or can't do with an enum. For 
>> libaries compiled from source, it won't affect performance at all—the 
>> compiler still knows the full set of cases in the current version of the 
>> library even if the programmer is forced to consider future versions.
>> 
>> I'm working on the fixed-contents proposal now, though it won't be ready for 
>> a while, and the same thing applies there: for structs compiled from source, 
>> the compiler can still do all the same optimizations. It's only when the 
>> library has binary compatibility concerns that we need to use extra 
>> indirection, and then "fixed-contents" becomes important. (As currently 
>> designed, it doesn't affect what clients can do with the struct at all.) 
>> This means that I don't expect a "normal" package author to write 
>> "fixed-contents" at all (however it ends up being spelled), whereas 
>> "exhaustive" is a fairly normal thing to consider whenever you make an enum 
>> public.
>> 
>> I hope that convinces you that "fixed-contents" and "exhaustive" don't need 
>> to have the same name. I don't think anyone loves the particular name 
>> "exhaustive", but as you see in the "Alternatives considered" we didn't 
>> manage to come up with anything significantly better. If reviewers all 
>> prefer something else we'd consider changing it.
>> 
>> Thanks for responding!
>> Jordan
>> 
> 
> When you say “libraries compiled from source”, what do you mean?

- Other targets in your project
- Source packages built through SwiftPM / CocoaPods / Carthage / other

And I was being imprecise with the terminology, but also

- Libraries built by someone else but designed to be embedded into an app, so 
that there's no chance of a different version showing up at run-time.

> 
> As for whether its a resilience feature: actually it is completely a 
> resilience feature. The effects on switching are only side-effects; really 
> what “exhaustive” or “nonexhaustive” are saying is literally that cases may 
> be added later. Even if we added private cases, you wouldn’t need to mark 
> those enums as specially exhaustive or not; that would be implied. It’s an 
> accommodation for things which don’t exist yet, so 

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Stephen Celis via swift-evolution]

Ah, sorry, I misread! For readability I think I'd still favor something like:

if let b = b {
  dict[a] = b
}

And I think some the arguments made in #0024 may still apply here, though feel 
free to discuss!

Stephen

> On Dec 21, 2017, at 1:37 PM, Benoit Pereira da silva  wrote:
> 
> Stephen,
> 
> You are right the proposal #0024 is very close.
> But in fact the logic is inverted.  
> 
> When using «=? » the right item is optional.
> a =? b assigns « b »  to « a »  only if « b »  is defined.
> So if an optional is defined =? will not erase its value.
> 
> But my real questions was…
> Do you have such operators that you really use very often?
> Should we incorporate bunches of new operators / micro-syntactic sugar?
> Is swift evolution the good place to discuss such question?
> 
> I don’t want to pollute your mail boxes.
> 
> Best regards,
> 
> B
> 
>> Le 21 déc. 2017 à 19:12, Stephen Celis > > a écrit :
>> 
>> Such an operator was proposed here: 
>> https://github.com/apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5547d0e0925/proposals/0024-optional-value-setter.md
>>  
>> 
>> 
>> It was ultimately rejected: 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/43.html
>>  
>> 
>> 
>> Stephen
>> 
>>> On Dec 21, 2017, at 11:44 AM, Benoit Pereira da silva via swift-evolution 
>>> > wrote:
>>> 
>>> Dear all,
>>> 
>>> That’s not ambitious but i think worth be explored.
>>> 
>>> What do you think for example of this Infix operator?
>>> « =? »  allows to express optional assignments  in a very concise way.
>>> 
>>> 
>>> // The `=? operator allows simplify optional assignements :
>>> //  `a = b ?? a` can be written : `a =? b`
>>> infix operator =?: AssignmentPrecedence
>>> 
>>> public func =? ( left:inout T?, right: T? ){
>>> left = right ?? left
>>> }
>>> 
>>> public func =? ( left:inout T, right: T? ){
>>> left = right ?? left
>>> }
>>> 
>>> 
>>> Do you have such operators that you really use very often?
>>> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.

___
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

[Dave Abrahams via swift-evolution]

> On Dec 21, 2017, at 10:19 AM, Ethan Diamond  wrote:
> 
> Just to clarify, Dave -
> 
> What happens there if one case has associated values

> and one has an associated value thats an optional? 
> 
> Enum A {
>case x(String?)
>case y
> }
> 
> let a = A.x(nil)

A.x is String??

> a.y // What's the result?

nil as Optional

> a.x // Would produce a double optional, which are clumsy to nil check

They’re a fact of life.  If that’s a problem, we should consider fixing it, but 
it’s orthogonal to this one.

> 
> I'm not a fan of solving this via synthesis in general. We have metatypes for 
> classes/structs/protocols, which are useful in all sorts of situations. Cases 
> are essentially "types" of enums. Why not have case metatypes? They're useful 
> for the same reasons class types are, and there's already precedence in the 
> language for syntax.

You mean “precedent?”  OK, but I don’t see how it helps with any of the same 
problems as synthesized properties for cases do.

> 
> 
> 
> On Thu, Dec 21, 2017 at 7:14 AM Dave Abrahams  > wrote:
> IIRC what we discussed was synthesizing  members of type Optional 
> which could then be checked against nil. 
> 
> if _ = x.failure { ... }
> if x.failure != nil { ... }
> if let r = x.success {...}
> 
> IMO synthesizing predicates would be a huge missed opportunity by comparison
> 
> Sent from my iPhone
> 
> On Dec 20, 2017, at 1:31 PM, Chris Lattner via swift-evolution 
> > wrote:
> 
>> In the past, we’ve discussed synthesizing predicate members onto enums.  
>> E.g. given:
>> 
>> enum E {
>>   case X
>>   case Y(Int)
>> }
>> 
>> you’d get something like:
>> 
>> extension E {
>>   func isX() -> Bool { return self == .X }
>>   func getY() -> Int? { … }
>> }
>> 
>> which would solve the client side of this nicely.
>> 
>> -Chris
>> 
>> 
>> 
>>> On Dec 20, 2017, at 11:24 AM, Ethan Diamond via swift-evolution 
>>> > wrote:
>>> 
>>> Sorry all for attaching the original post to the Non-Exhaustive enums 
>>> thread. I"m moving it down to it's own thread. 
>>> 
>>> My understanding is I'm not allowed to write up a proposal unless I have 
>>> the time to implement it. Is that still true? This is a major pain point 
>>> for me to avoid having to write things like this:
>>> 
>>> if case .search = presenter.state { return true } else { return false }
>>> 
>>> Side note: Thanks Kevin, didn't know you could nest enums in switches like 
>>> that. Super helpful!
>>> 
>>> --
>>> I thought I would add another case that isn’t possible with current syntax 
>>> (so far as I’m aware).  You can’t negate the comparison to do something for 
>>> all cases except a particular case.  You have to have an empty if block and 
>>> use the else block, or have an empty case in a switch statement and use the 
>>> default.
>>> 
>>> enum Enum {
>>>   case a(param: String)
>>>   case b(param: String)
>>>   case c(param: String)
>>> }
>>> 
>>> let enumeration: Enum = .a(param: "Hi")
>>> 
>>> if !(case .a = enumeration) {
>>>   // Do something
>>> }
>>> 
>>> — Charles
>>> 
>>> > On Dec 20, 2017, at 9:55 AM, Kevin Nattinger via swift-evolution 
>>> > >> > > wrote:
>>> > 
>>> > I agree this would be useful. At the moment I have to hack around it with 
>>> > things like `var isFoo: Bool { if case .foo = self …`* with cases I 
>>> > commonly need, but this is definitely a feature that has come up before 
>>> > and I support. It is potentially related to getting the values through an 
>>> > accessor, which has also come up several times.
>>> > 
>>> > Sidenote, your `switch` example is actually trivial with existing syntax:
>>> > 
>>> > switch enumeration {
>>> > case .a(.c(let param)): // or just .a(.c) if you don't need the value
>>> > print(param)
>>> > default:
>>> > break
>>> > }
>>> > 
>>> > I use this from time to time switching over, e.g., optional enums.
>>> > 
>>> > *: ugliest syntax ever, and it can't even be used as a standalone 
>>> > expression.
>>> > 
>>> > 
>>> >> On Dec 20, 2017, at 8:44 AM, Ethan Diamond via swift-evolution 
>>> >> >> >>  
>>> >> >> >> >> 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:

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

[Jordan Rose via swift-evolution]

Thanks for your response, Ash. Comments inline.


> On Dec 20, 2017, at 11:49, Ash Furrow via swift-evolution 
>  wrote:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>  
> 
> 
> What is your evaluation of the proposal?
> 
> -1.
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> I’m afraid not.
> 
> From my perspective as a Swift user, this change represents nontrivial 
> language churn without providing a solution to a problem I have. The proposal 
> doesn’t describe any benefits to me as an open source library maintainer or 
> as a Swift developer. With earnest respect, the motivation section reads like 
> “enums grow sometimes, but we like to exhaustively switch over them, so 
> wouldn’t it be cool if …”, which is only a theoretical motivation. It fails 
> to describe how and why this proposal would improve my Swift code or my 
> experience using Swift.
> 
> This appears to be a solution to a non-existing problem. I worry that making 
> this change will alienate developers from Swift and I caution against 
> accepting it.
> 
I wish it were, but unfortunately it's a very real problem. Cases are added to 
Cocoa all the time, and currently it is undefined behavior if one of those 
cases makes it into a switch defined in Swift. ("undefined behavior" = "no 
guarantees of memory safety, type safety, or even which functions are going to 
get invoked in the rest of the function") This is a terrible state of affairs 
that we need to do something about, and "make it a deterministic trap" isn't a 
good enough answer.

We also already know that we have clients that want to add new cases to Swift 
enums without breaking source or binary compatibility: the Apple overlays. It's 
true that this is more of a "theoretical motivation" for source framework 
authors at this time.



> Does this proposal fit well with the feel and direction of Swift?
> 
> It may have at one time point in time, but not now.
> 
> The chaotic churn of the language, the syntax, and the standard library is 
> supposed to be behind us. We need to accept that things fell into place as 
> they did, often in imperfect ways. We probably could correct all the 
> imperfections, but when would we ever stop? Language churn has a cost. This 
> proposal is something that I could definitely see being a part of Swift 2 or 
> Swift 3, but we have already decided that enums are exhaustive. This change, 
> and changes fundamental to the cognitive model Swift programmers already have 
> of their tool, need to be heavily weighted against language churn

There's a difference between imperfections that mean something is a bit harder 
to use, or not named the right thing, and imperfections that lead to crashes or 
core capabilities not being expressible. Being able to add cases to enums is 
something Cocoa developers have relied on for years in Objective-C, and so it 
isn't really sensible to not have this feature in Swift. I definitely wish we 
could have gotten to it sooner.


> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> Scala’s match syntax bears a striking resemblance to Swift’s switch syntax; 
> however, Scala does not require exhaustive cases. If the developer does not 
> include a default case and none of the cases match the expression, an 
> exception is thrown. Because of Swift’s error-handling model, I don’t know 
> that this behaviour would be desirable either (though I will say it makes 
> sense in Scala).

This is certainly an option; it's in the proposal under "Alternatives 
considered" as 'switch!' (causing a deterministic trap rather than an 
exception). That doesn't seem sufficient to deal with the realities of Cocoa, 
though.

Jordan


> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> I read most of the proposal (okay I skimmed some of the nitty-gritty, but I 
> read to the end of “Source compatibility”) as well as looked over the 
> pre-review threads and skimmed GitHub pull request thread.
> 
> -- 
> Ash Furrow
> https://ashfurrow.com/ 
> On December 19, 2017 at 5:58:14 PM, Ted Kremenek via swift-evolution 
> (swift-evolution@swift.org ) 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 

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Benoit Pereira da silva via swift-evolution]

Stephen,

You are right the proposal #0024 is very close.
But in fact the logic is inverted.  

When using «=? » the right item is optional.
a =? b assigns « b »  to « a »  only if « b »  is defined.
So if an optional is defined =? will not erase its value.

But my real questions was…
Do you have such operators that you really use very often?
Should we incorporate bunches of new operators / micro-syntactic sugar?
Is swift evolution the good place to discuss such question?

I don’t want to pollute your mail boxes.

Best regards,

B

> Le 21 déc. 2017 à 19:12, Stephen Celis  a écrit :
> 
> Such an operator was proposed here: 
> https://github.com/apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5547d0e0925/proposals/0024-optional-value-setter.md
>  
> 
> 
> It was ultimately rejected: 
> https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/43.html
>  
> 
> 
> Stephen
> 
>> On Dec 21, 2017, at 11:44 AM, Benoit Pereira da silva via swift-evolution 
>> > wrote:
>> 
>> Dear all,
>> 
>> That’s not ambitious but i think worth be explored.
>> 
>> What do you think for example of this Infix operator?
>> « =? »  allows to express optional assignments  in a very concise way.
>> 
>> 
>> // The `=? operator allows simplify optional assignements :
>> //  `a = b ?? a` can be written : `a =? b`
>> infix operator =?: AssignmentPrecedence
>> 
>> public func =? ( left:inout T?, right: T? ){
>> left = right ?? left
>> }
>> 
>> public func =? ( left:inout T, right: T? ){
>> left = right ?? left
>> }
>> 
>> 
>> Do you have such operators that you really use very often?
>> 

Benoit Pereira da Silva
Ultra Mobile Developer & Movement Activist
Développeur Ultra Mobile & Militant du mouvement
https://pereira-da-silva.com 





✄ 
This e-mail is confidential. Distribution, copy, publication or use of this 
information for any purpose is prohibited without agreement of the sender.
Ce message est confidentiel. Toute distribution, copie, publication ou usage 
des informations contenues dans ce message sont interdits sans agrément 
préalable de l'expéditeur.



___
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

[Kevin Nattinger via swift-evolution]

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

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

[Jordan Rose via swift-evolution]

[Proposal: 
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md]

> On Dec 21, 2017, at 09:49, Ignacio Soto via swift-evolution 
>  wrote:
> 
> I think I speak for the entire Swift community when I say that Swift's enums, 
> together with the ability to switch over them exhaustively and having 
> compile-time guarantees, is one of the best features in Swift. I'm regularly 
> annoyed by this when writing other languages like Java and JS (default: throw 
> new IllegalArgumentException();)
> 
> Now, that's not to say I don't understand why this proposal is necessary. I 
> totally get it, and the existing decisions make a lot of sense to me. But I'd 
> like us to introduce this while maintaining the ability to guarantee 
> exhaustive switch statements, no matter how the enum was defined.
> 
> Example: imagine a theoretical SampleKit defines:
> public enum E {
> case A
> case B
> }
> 
> It's implicitly non-exhaustive, possibly because the author was not aware of 
> the default (which would likely happen often), or possibly because they made 
> a conscious decision, as they expect to expand the cases in the future.
> 
> In my app, I use SampleKit and decide that I want to make sure I handle all 
> cases:
> 
> switch e {
> case A: break
> case B: break
> default: break // This becomes necessary
> }
> 
> As the proposal stands right now, I'm forced to handle any future cases. 
> That's fine. What's not fine in my opinion, is that in doing so I lose the 
> ability to keep this exhaustiveness moving forward. If I update SampleKit to 
> v2.0, I want to know at compile-time if there are new cases I need to be 
> aware of (instead of going to some generic handling path). Instead, I’m left 
> in the same place I would in other languages like Java or JS:
> 
> // No error :(
> switch e {
> case A: break
> case B: break
> default: break
> }
> 
> Proposed Solution
> 
> What I’m proposing is that we introduce a new keyword, unknown (or a better 
> name), that serves as a way to handle cases that aren’t yet known, but not 
> those that are.
> 
> // Error: missing case C
> switch e {
> case A: break
> case B: break
> unknown: break // Would handle future cases
> }
> 
> With this, you shouldn’t be able to use default AND unknown at the same time, 
> as default implicitly includes unknown.
> 
> Thanks for reading, and I hope you can consider this change (or some 
> variation of it).

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?

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

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

[Ethan Diamond via swift-evolution]

Just to clarify, Dave -

What happens there if one case has associated values and one has an
associated value thats an optional?

Enum A {
   case x(String?)
   case y
}

let a = A.x(nil)

a.y // What's the result?
a.x // Would produce a double optional, which are clumsy to nil check

I'm not a fan of solving this via synthesis in general. We have metatypes
for classes/structs/protocols, which are useful in all sorts of situations.
Cases are essentially "types" of enums. Why not have case metatypes?
They're useful for the same reasons class types are, and there's already
precedence in the language for syntax.



On Thu, Dec 21, 2017 at 7:14 AM Dave Abrahams  wrote:

> IIRC what we discussed was synthesizing  members of type Optional
> which could then be checked against nil.
>
> if _ = x.failure { ... }
> if x.failure != nil { ... }
> if let r = x.success {...}
>
> IMO synthesizing predicates would be a huge missed opportunity by
> comparison
>
> Sent from my iPhone
>
> On Dec 20, 2017, at 1:31 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> In the past, we’ve discussed synthesizing predicate members onto enums.
> E.g. given:
>
> enum E {
>   case X
>   case Y(Int)
> }
>
> you’d get something like:
>
> extension E {
>   func isX() -> Bool { return self == .X }
>   func getY() -> Int? { … }
> }
>
> which would solve the client side of this nicely.
>
> -Chris
>
>
>
> On Dec 20, 2017, at 11:24 AM, Ethan Diamond via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Sorry all for attaching the original post to the Non-Exhaustive enums
> thread. I"m moving it down to it's own thread.
>
> My understanding is I'm not allowed to write up a proposal unless I have
> the time to implement it. Is that still true? This is a major pain point
> for me to avoid having to write things like this:
>
> if case .search = presenter.state { return true } else { return false }
> Side note: Thanks Kevin, didn't know you could nest enums in switches like
> that. Super helpful!
>
> --
>
> I thought I would add another case that isn’t possible with current syntax 
> (so far as I’m aware).  You can’t negate the comparison to do something for 
> all cases except a particular case.  You have to have an empty if block and 
> use the else block, or have an empty case in a switch statement and use the 
> default.
>
> enum Enum {
>   case a(param: String)
>   case b(param: String)
>   case c(param: String)
> }
>
> let enumeration: Enum = .a(param: "Hi")
>
> if !(case .a = enumeration) {
>   // Do something
> }
>
> — Charles
>
> >* On Dec 20, 2017, at 9:55 AM, Kevin Nattinger via swift-evolution 
> > >> wrote:
> *> >* I agree this would be useful. At the moment I have to hack around it 
> with things like `var isFoo: Bool { if case .foo = self …`* with cases I 
> commonly need, but this is definitely a feature that has come up before and I 
> support. It is potentially related to getting the values through an accessor, 
> which has also come up several times.
> *> >* Sidenote, your `switch` example is actually trivial with existing 
> syntax:
> *> >* switch enumeration {
> *>* case .a(.c(let param)): // or just .a(.c) if you don't need the value
> *>* print(param)
> *>* default:
> *>* break
> *>* }
> *> >* I use this from time to time switching over, e.g., optional enums.
> *> >* *: ugliest syntax ever, and it can't even be used as a standalone 
> expression.
> *> > >>* On Dec 20, 2017, at 8:44 AM, Ethan Diamond via swift-evolution 
>   
>  >> 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: 

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

[Tino Heth via swift-evolution]

> What I’m proposing is that we introduce a new keyword, unknown (or a better 
> name), that serves as a way to handle cases that aren’t yet known, but not 
> those that are.
Afaics, the best this could do is helping when a compiled library using 
another, updated library with new cases in a switch — but in the common case, 
that enum would be used in the source code of an app.
So, to be useful, you’ll need some sort of version annotation in your source, 
or the compiler will not be able to tell which cases have been added since you 
wrote a switch.

Also, I really don’t think that exhaustive switching on „alien“ enums is one of 
the best features in Swift (of course, that depends on what count you allow for 
a feature to be one of the best ;-):
At least, I don’t see big harm in the proposal. I haven’t seen many examples of 
framework-defined enums that are extended, and used in switch-statements in 
client code.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Stephen Celis via swift-evolution]

Such an operator was proposed here: 
https://github.com/apple/swift-evolution/blob/60a8980a66a0a1341871ec323797c5547d0e0925/proposals/0024-optional-value-setter.md

It was ultimately rejected: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/43.html

Stephen

> On Dec 21, 2017, at 11:44 AM, Benoit Pereira da silva via swift-evolution 
>  wrote:
> 
> Dear all,
> 
> That’s not ambitious but i think worth be explored.
> 
> What do you think for example of this Infix operator?
> « =? »  allows to express optional assignments  in a very concise way.
> 
> 
> // The `=? operator allows simplify optional assignements :
> //  `a = b ?? a` can be written : `a =? b`
> infix operator =?: AssignmentPrecedence
> 
> public func =? ( left:inout T?, right: T? ){
> left = right ?? left
> }
> 
> public func =? ( left:inout T, right: T? ){
> left = right ?? left
> }
> 
> 
> Do you have such operators that you really use very often?
> 
> 
> 
> Best regards 
> 
> Benoit
> 
> 
> 
> Benoit Pereira da Silva
> Ultra Mobile Developer & Movement Activist
> Développeur Ultra Mobile & Militant du mouvement
> https://pereira-da-silva.com 
> 
> 
> 
> 
> 
> ✄ 
> This e-mail is confidential. Distribution, copy, publication or use of this 
> information for any purpose is prohibited without agreement of the sender.
> Ce message est confidentiel. Toute distribution, copie, publication ou usage 
> des informations contenues dans ce message sont interdits sans agrément 
> préalable de l'expéditeur.
> 
> 
> 
> ___
> 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

[Dave DeLong via swift-evolution]

I realized further why we should not implement this proposal: It forces the 
problem of binary compatibility on the app developer, when experience has shown 
us that problem is better handled by the libraries.

Binary Compatibility

“Binary compatibility” is the notion that, even if the libraries you link 
against change, your app will still behave as it did when it was first 
compiled. For Swift apps these days, we don’t really have this problem, *yet*. 
We do have the problem of “binary compatibility” with Apple-provided 
frameworks, but those are all written in Objective-C, and so the question of 
“Swift” binary compatibility is still up-in-the-air.

Post-ABI stability, we still won’t have much issue with swift binary 
compatibility on Apple platforms, because there isn’t a mechanism to ship a 
framework to your users independently of an app update. So from the app POV, 
none of this will be a problem for Apple platform developers.

It will be a problem for non-Apple platform developers. As a simple example, 
let’s say I write a web app in Swift, and deploy it to a server that has some 
built-in Swift-on-the-server libraries. Here, my Swift app is decoupled from 
the libraries, and either one can update independently of each other. If the 
server owner decides to update from Swift 6 to Swift 6.1, that’s cool. But my 
web app should continue to run and behave *as if* the server were still running 
Swift 6, because it has not been re-compiled to use Swift 6.1 features.

This is the situation today on Apple platforms. Every app deployed to an Apple 
device includes a little piece of information in the executable file indicating 
which SDK was used to compile the app. At runtime, the system frameworks read 
this value and then alter their behavior accordingly. This is why apps written 
against the iOS 9 SDK continue to work on iOS 11 devices; UIKit and friends are 
altering their behavior to provide iOS 9 semantics. 

This is “binary compatibility”: the binary (your app) continues to be 
compatible with the dynamically linked frameworks present on the system, even 
though those frameworks may change.

When you have a setup where the frameworks do NOT provide binary compatibility, 
you end up in DLL Hell [1]. This is the same frustrating scenario when you’re 
in when you’re doing stuff with homebrew and find that this package you want 
has multiple dependencies, but these dependencies want different versions of 
the same library. [2]

Exhaustive Enums

All of the discussion around exhaustive enums has been from the point-of-view 
of “what should the behavior be when the libraries change”. Thinking back, I’m 
actually surprised this is a question at all, because Apple answered this 
*years* ago: THE BEHAVIOR SHOULD REMAIN UNCHANGED. It is up to the library 
authors to ensure that they’re doing what the compiled-and-unchanging 
application is expecting them to do.

This discussion around exhaustive enums is basically saying “can we force the 
developers to deal with binary incompatibility?”. We absolutely should not. 
There are far more app developers than library developers, and it would be a 
massively wasteful expenditure of engineering effort to force each and every 
app developer to deal with binary incompatibility, when the library can do it 
for them. That is the entire *purpose* of having libraries: abstract out a 
problem so that I, as an app developer, don’t have to spend the effort to do it 
myself.

Where We Should Go

Instead of forcing developers to deal with incompatible libraries, we should be 
discussing ways to make binary compatibility easier to implement in libraries.

One of the major problems I struggled with as a UIKit engineer was the presence 
of huge numbers of “if … else” checks in the code to deal with binary 
compatibility. It exploded the cyclomatic complexity of the classes and was a 
major source of technical debt that I struggled to not add to.

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.

But forcing developers to deal with binary incompatibility is a solution we’ve 
long known to be a bad one. We should not perpetuate that sin in Swift.

Dave

[1]: https://en.wikipedia.org/wiki/DLL_Hell 

[2]: https://en.wikipedia.org/wiki/Dependency_hell 



> On Dec 20, 2017, at 10:23 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> 
> 
>> On Dec 19, 2017, at 3: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:
>> 
>> 

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

[Kevin Nattinger via swift-evolution]

> 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
>  
> 
> What is your evaluation of the proposal?
> 
I was going to say -100 without future, +1 with, but other arguments on this 
thread have put me on the fence to mildly against, so -100 without future, -ε 
with.


In the proposal, there is the following text:
> The consequences of losing exhaustiveness checking for non-exhaustive enums 
> are discussed in the "Alternatives considered" section at the end of this 
> proposal.
> 
> A number of pre-reviewers have been concerned about the loss of 
> exhaustiveness checking and the subsequent difficulty in updating to a new 
> version of a dependency. In the original swift-evolution thread, Vladimir S. 
> describes the concerning scenario 
> 
>  in detail.
I find it deeply disturbing that this scenario is acknowledged as "concerning" 
and yet ignored without justification in the proposal proper, and in the 
"alternatives" dismissed solely based on a baseless assumption—that the 
situation will be "uncommon." Even if it were an uncommon case, the negative 
impact is still dire enough and without a good workaround that I'd argue 
strongly that the concern be addressed properly.

The justification put forward to reject a `future` case is that "The 
expectation is that switches over non-exhaustive enums are uncommon." However, 
there is no evidence to support that assertion, and there are a huge number of 
enums in even just Apple's frameworks that people reasonably can, and in some 
cases really should, switch over. Go through any of the iOS frameworks and find 
authorization enums and delegates with enums in a callback, and you're likely 
to find some that it makes sense for a client to switch over. Just a few off 
the top of my head that I have personally switched on:

CoreBluetooth
- CBManagerState
- CBPeripheralManagerAuthorizationStatus
- CBPeripheralState
CoreLocation
- CLAuthorizationStatus
- CLActivityType
CoreData
- NSFetchedResultsChangeType
MessageUI
- MessageComposeResult
UIKit
- UITableViewCellEditingStyle

Every framework that requires user permission has its own authorization enum, 
many have an additional state enum, and for most delegate callbacks with an 
enum argument it's often a good idea to switch over the cases.

As a real-life example above and beyond the one referenced above, In the fairly 
small codebase I'm working in at the moment, I count a bit over 12klocs, 80-ish 
switches, and 6 switches that would need a `future` case (non-exhaustive, from 
Apple frameworks). That's about one per 2klocs, It probably wouldn't scale 
linearly in larger projects, but just their prevalence in the apple frameworks 
as I pointed out above would suggest it does grow significantly.

The extra onus on project authors required by not including a future case for 
those cases would make upgrading libraries and iOS versions incredibly 
difficult and error-prone. To ensure correctness, you would have to go over 
every single switch in your app, figure out the type it's switching on, and if 
the type is external and nonexhaustive, check that there are no new cases. Even 
if this is "not expected to be the common case," omitting the `future` means 
you have to either keep track of where all your relevant switch statements are 
and check them on every upgrade, go through and evaluate every switch statement 
to figure out whether you need to check for extra cases, or go through the API 
diff, find any added enum cases, and find every switch in your codebase that 
switches on them. All three options are dangerously error-prone and 
unacceptable.

In summary, failing to include a future case but requiring default instead 
would place an unacceptable burden on every nontrivial project every time a 
library is upgraded and (and I don't say this lightly) would almost certainly 
be the biggest mistake the Swift community has ever made.

There is an existing implementation along with the PR, so has anyone tried this 
change a project of significant size that uses a variety of Apple frameworks? 
How many `default`s did you have to put in that should be `future`, and how 
would you feel about having to find all those places again and any more that 
may be put in in a year or two *without* compiler checking?
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
The problem needs to be addressed, certainly.
> Does this proposal fit well with the feel and direction of Swift?
> 
With future, sure. Without, absolutely not. As demonstrated 

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

[Ignacio Soto via swift-evolution]

I think I speak for the entire Swift community when I say that Swift's enums, 
together with the ability to switch over them exhaustively and having 
compile-time guarantees, is one of the best features in Swift. I'm regularly 
annoyed by this when writing other languages like Java and JS (default: throw 
new IllegalArgumentException();)

Now, that's not to say I don't understand why this proposal is necessary. I 
totally get it, and the existing decisions make a lot of sense to me. But I'd 
like us to introduce this while maintaining the ability to guarantee exhaustive 
switch statements, no matter how the enum was defined.

Example: imagine a theoretical SampleKit defines:
public enum E {
case A
case B
}

It's implicitly non-exhaustive, possibly because the author was not aware of 
the default (which would likely happen often), or possibly because they made a 
conscious decision, as they expect to expand the cases in the future.

In my app, I use SampleKit and decide that I want to make sure I handle all 
cases:

switch e {
case A: break
case B: break
default: break // This becomes necessary
}

As the proposal stands right now, I'm forced to handle any future cases. That's 
fine. What's not fine in my opinion, is that in doing so I lose the ability to 
keep this exhaustiveness moving forward. If I update SampleKit to v2.0, I want 
to know at compile-time if there are new cases I need to be aware of (instead 
of going to some generic handling path). Instead, I’m left in the same place I 
would in other languages like Java or JS:

// No error :(
switch e {
case A: break
case B: break
default: break
}

Proposed Solution

What I’m proposing is that we introduce a new keyword, unknown (or a better 
name), that serves as a way to handle cases that aren’t yet known, but not 
those that are.

// Error: missing case C
switch e {
case A: break
case B: break
unknown: break // Would handle future cases
}

With this, you shouldn’t be able to use default AND unknown at the same time, 
as default implicitly includes unknown.

Thanks for reading, and I hope you can consider this change (or some variation 
of it).

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

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

[Pitiphong Phongpattranont via swift-evolution]

Hello I would like to give a feedback on this SE,

In the proposal, it stats that
In the initial discussion, multiple people were unhappy with the loss of 
compiler warnings for switches over non-exhaustive enums that comes with using 
default—they wanted to be able to handle all cases that exist today, and have 
the compiler tell them when new ones were added. Ultimately I decided not to 
include this in the proposal with the expectation is that switches over 
non-exhaustive enums should be uncommon.

This may not be true for every Swift based app. My scenario is that we are a 
service company who have a open source library for our customer to integrate 
our service into their app. However we also have an official application which 
also uses these libraries too. And since we adopted Swift features as much as 
possible, we do have a lot of public enum types in our libraries and use them 
in our app heavily. This PR will make our code base harder to maintain since we 
lost the complier warning for switches over non-exhaustive enums

I understand that most of the Swift based apps may not suffer from this heavily 
like us but when they do, it’s really a huge pain to maintain this.

Best regards,
Pitiphong P.



> On 20 Dec BE 2560, at 05:58, Ted Kremenek  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?
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce

___
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

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

[Chris Lattner via swift-evolution]

> 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
>  
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
I'm strongly in favor of it.  This is important to resolve as part of the ABI 
stability and binary frameworks projects which are top goals of Swift 5.
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
Yes.
> Does this proposal fit well with the feel and direction of Swift?
> 
Yes, absolutely, in a couple of ways:

 - This design abides by the goal of progressive disclosure: you’re completely 
unaffected by it (and don’t have to think about it) until you are publishing a 
public enum outside of your module.
 - This is a "safe default”: if someone forgets to think about how their enum 
will be used, it will design to being non-exhaustive.  If this becomes a 
problem in practice for their clients, they’d get notified of that and can 
(without breaking abi compatibility with previous releases) opt into 
exhaustiveness.  If the parity is reversed, this won’t be the case.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
Swift is an uncommon language because it aims to support both static 
compilation and long-term API/ABI stability.  Many other languages choose one 
over the other: e.g. C++ is good at static compilation, but not long-term 
API/ABI stability (fragile base class problem, and C enums, etc).  Java is good 
at long-term API stability, but not great for static compilation.

The closest analog I’m familiar with is the Objective- part of Objective-C, 
which is great at API/ABI stability .  Unfortunate, it inherited its enum model 
from C, and we are well aware of how problematic they are for framework 
evolution.  This approach is a great solution to the problems found through 
decades of experience evolving APIs that use these C enums.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 

A lot of time.

-Chris


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

[swift-evolution] Should we incorporate bunches of new operators / micro-syntactic sugar?

[Benoit Pereira da silva via swift-evolution]

Dear all,

That’s not ambitious but i think worth be explored.

What do you think for example of this Infix operator?
« =? »  allows to express optional assignments  in a very concise way.


// The `=? operator allows simplify optional assignements :
//  `a = b ?? a` can be written : `a =? b`
infix operator =?: AssignmentPrecedence

public func =? ( left:inout T?, right: T? ){
left = right ?? left
}

public func =? ( left:inout T, right: T? ){
left = right ?? left
}


Do you have such operators that you really use very often?



Best regards 

Benoit



Benoit Pereira da Silva
Ultra Mobile Developer & Movement Activist
Développeur Ultra Mobile & Militant du mouvement
https://pereira-da-silva.com 





✄ 
This e-mail is confidential. Distribution, copy, publication or use of this 
information for any purpose is prohibited without agreement of the sender.
Ce message est confidentiel. Toute distribution, copie, publication ou usage 
des informations contenues dans ce message sont interdits sans agrément 
préalable de l'expéditeur.



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

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

[Natchanon Luangsomboon via swift-evolution]

Oops, I meant to post this on a separate thread. Sorry.

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

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

[Natchanon Luangsomboon via swift-evolution]

Before answering above, I would like to add
Since the users of the library will likely not accommodate the new cases (as it 
doesn’t exist yet), the `default/future` case will then not provide any real 
usage other than throwing exceptions. So the user will still need to update the 
code to actually accommodate these cases. This proposal doesn’t solve any real 
problem (more than what Swift 4 is currently doing).
Non-exhaustive behavior already exist as the `default` case, which user can 
op-in. So the decision on whether or not the enum is `exhaustive` is currently 
users’. This proposal will shift this decision to the author of the library, 
not the user. This is a huge minus since it moved the responsibility to one 
individual (or a single group of individual) rather than the actual users, and 
also reduce configurability (the user will have little say in whether or not an 
enum is exhaustive).
>From my own experience, most of the time I use `switch`, I intentionally omit 
>`default`, so the when the library update, I do know which portion needs to 
>handle new cases (among other things). If any enum is decided by the author to 
>be non-exhaustive, it would take away this ability. This refers back to 
>previous bullet point.
What is your evaluation of the proposal?
This is a -1.
The ABI resilience can be a plus, but the requiring change in behavior is a 
huge minus, esp. the effect on users’ side of the library. 
Is the problem being addressed significant enough to warrant a change to Swift?
I do see where this problem may arise, but the solution has too much drawback 
to be included in Swift.
Does this proposal fit well with the feel and direction of Swift?
This doesn’t fit well with the feel and direction of the Swift.
As mentioned above, the proposal shift decision on whether or not to support 
(or to require support) future cases to the author of library, not the users. 
IMO, it is not very Swifty (or even a good idea).
If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
I used languages with non-exhaustive enum before, I can never go back after 
using the exhaustive one.
How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?
A several read through the proposal. I really try to like this proposal, as I 
see that the problem exists, but the solution still doesn’t sound.

Sincerely,
Natchanon

> On Tue, Dec 19, 2017 at 11:58 PM, Ted Kremenek  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?
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> 
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
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]

> On 21 Dec 2017, at 4:06 pm, Johannes Weiß via swift-evolution 
>  wrote:
> 
>> 
>> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>>  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
>> 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/0193-cross-module-inlining-and-specialization.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?
> 
> I'm working on a performance sensitive library and we're sometimes bitten 
> quite hard by not being able to cross-module inline & specialise. Therefore, 
> it's thrilling to see that you're working in this area.
> 
> However, I have to admit that I believe this language feature will most 
> likely be grossly abused. 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.
> 
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> see above.
> 
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> to back up the 'swift' claim, cross-module inlining & specialisation is 
> absolutely necessary. However this should also be achievable with a 'I don't 
> need a stable ABI for this product' mode in the compiler :).
> 
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> 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.

forgot to mention GHC's -fspecialise-aggressively which is its way of saying, 
just specialise things across modules even without '{-# INLINABLE ... #-}' 
which is basically the compilation mode I'm asking for :).

> 
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> read the proposal (and believe to understand it).
> 
> -- Johannes
> 
>> 
>> 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

___
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]

> On 21 Dec 2017, at 12:19 am, Ted Kremenek via swift-evolution 
>  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
> 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/0193-cross-module-inlining-and-specialization.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?

I'm working on a performance sensitive library and we're sometimes bitten quite 
hard by not being able to cross-module inline & specialise. Therefore, it's 
thrilling to see that you're working in this area.

However, I have to admit that I believe this language feature will most likely 
be grossly abused. 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.


>   • Is the problem being addressed significant enough to warrant a change 
> to Swift?

see above.


>   • Does this proposal fit well with the feel and direction of Swift?

to back up the 'swift' claim, cross-module inlining & specialisation is 
absolutely necessary. However this should also be achievable with a 'I don't 
need a stable ABI for this product' mode in the compiler :).


>   • If you have used other languages or libraries with a similar feature, 
> how do you feel that this proposal compares to those?

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.


>   • How much effort did you put into your review? A glance, a quick 
> reading, or an in-depth study?

read the proposal (and believe to understand it).

-- Johannes

> 
> 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] Evaluating the case of an enum with associated values as a bool

[Dave Abrahams via swift-evolution]

IIRC what we discussed was synthesizing  members of type Optional 
which could then be checked against nil. 

if _ = x.failure { ... }
if x.failure != nil { ... }
if let r = x.success {...}

IMO synthesizing predicates would be a huge missed opportunity by comparison

Sent from my iPhone

> On Dec 20, 2017, at 1:31 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> In the past, we’ve discussed synthesizing predicate members onto enums.  E.g. 
> given:
> 
> enum E {
>   case X
>   case Y(Int)
> }
> 
> you’d get something like:
> 
> extension E {
>   func isX() -> Bool { return self == .X }
>   func getY() -> Int? { … }
> }
> 
> which would solve the client side of this nicely.
> 
> -Chris
> 
> 
> 
>> On Dec 20, 2017, at 11:24 AM, Ethan Diamond via swift-evolution 
>>  wrote:
>> 
>> Sorry all for attaching the original post to the Non-Exhaustive enums 
>> thread. I"m moving it down to it's own thread. 
>> 
>> My understanding is I'm not allowed to write up a proposal unless I have the 
>> time to implement it. Is that still true? This is a major pain point for me 
>> to avoid having to write things like this:
>> 
>> if case .search = presenter.state { return true } else { return false }
>> 
>> Side note: Thanks Kevin, didn't know you could nest enums in switches like 
>> that. Super helpful!
>> 
>> --
>> I thought I would add another case that isn’t possible with current syntax 
>> (so far as I’m aware).  You can’t negate the comparison to do something for 
>> all cases except a particular case.  You have to have an empty if block and 
>> use the else block, or have an empty case in a switch statement and use the 
>> default.
>> 
>> enum Enum {
>>   case a(param: String)
>>   case b(param: String)
>>   case c(param: String)
>> }
>> 
>> let enumeration: Enum = .a(param: "Hi")
>> 
>> if !(case .a = enumeration) {
>>   // Do something
>> }
>> 
>> — Charles
>> 
>> > On Dec 20, 2017, at 9:55 AM, Kevin Nattinger via swift-evolution 
>> >  wrote:
>> > 
>> > I agree this would be useful. At the moment I have to hack around it with 
>> > things like `var isFoo: Bool { if case .foo = self …`* with cases I 
>> > commonly need, but this is definitely a feature that has come up before 
>> > and I support. It is potentially related to getting the values through an 
>> > accessor, which has also come up several times.
>> > 
>> > Sidenote, your `switch` example is actually trivial with existing syntax:
>> > 
>> > switch enumeration {
>> > case .a(.c(let param)): // or just .a(.c) if you don't need the value
>> > print(param)
>> > default:
>> > break
>> > }
>> > 
>> > I use this from time to time switching over, e.g., optional enums.
>> > 
>> > *: ugliest syntax ever, and it can't even be used as a standalone 
>> > expression.
>> > 
>> > 
>> >> On Dec 20, 2017, at 8:44 AM, Ethan Diamond via swift-evolution 
>> >> mailto:swift-evolution at 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 

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

[Chris Eidhof via swift-evolution]

I can see why this is useful, and understand the problem. However, it does
feel like the wrong solution to a real problem. This seems to be very
similar to the *expression problem*:

> The expression problem is a new name for an old problem.[2][3] The goal
is to define a datatype by cases, where one can add new cases to the
datatype and new functions over the datatype, without recompiling existing
code, and while retaining static type safety (e.g., no casts).
>
> (source: https://en.wikipedia.org/wiki/Expression_problem)

The price we'll pay for this proposal is to always have a default case with
non-exhaustive enums. To me, this feels very similar to the default case in
Swift's error handling, and in that sense it matches the existing language
behavior. However, I find the default case in Swift's error handling quite
annoying (especially if you can guarantee you've handled all possible
errors).

In the case of enums, I'd much rather get a compiler error because I didn't
handle case, than a runtime error because my default caught a case I
actually wanted to catch. Having non-exhaustive enums makes it much harder
to refactor code that uses those enums (if I add a case, the compiler
doesn't give me a list of all the sites I need to fix).

A -1 from me.

I would like a solution to the problem, but I feel that the proposed
solution has too many drawbacks.


On Tue, Dec 19, 2017 at 11:58 PM, Ted Kremenek  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?
>-
>
>Is the problem being addressed significant enough to warrant a change
>to Swift?
>-
>
>Does this proposal fit well with the feel and direction of Swift?
>-
>
>If you have used other languages or libraries with a similar feature,
>how do you feel that this proposal compares to those?
>-
>
>How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
>
> Thanks,
> Ted Kremenek
> Review Manager
>
> ___
> swift-evolution-announce mailing list
> swift-evolution-annou...@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
>


-- 
Chris Eidhof
___
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

[Letanyan Arumugam via swift-evolution]

> On 21 Dec 2017, at 05:16, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>>  wrote:
>> 
>>  • What is your evaluation of the proposal?
> 
> I am pleased with the broad strokes of this design. I have quibbles with 
> three areas:
> 
> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
> suggest versioning. My best alternative suggestion is `@frozen`, which 
> matches existing programming terminology: something that has been frozen will 
> not be changed in the future.
> 
> 

I like frozen, but what is its opposite? Is it still non-exhaustive?

___
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

[Sebastian Hagedorn via swift-evolution]

+1 on @frozen and John’s reasoning.


> On 21. Dec 2017, at 04:32, John McCall via swift-evolution 
>  wrote:
> 
>> 
>> On Dec 20, 2017, at 10:16 PM, Brent Royal-Gordon via swift-evolution 
>> > wrote:
>> 
>>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>>> > wrote:
>>> 
>>> • What is your evaluation of the proposal?
>> 
>> I am pleased with the broad strokes of this design. I have quibbles with 
>> three areas:
>> 
>> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
>> suggest versioning. My best alternative suggestion is `@frozen`, which 
>> matches existing programming terminology: something that has been frozen 
>> will not be changed in the future.
> 
> I rather like @frozen.  We could use that across language features, so that 
> we don't end up with a keyword per kind of declaration.
> 
> John.
> 
>> 
>> 2. I think we need some kind of `future` keyword in `switch` statements. 
>> Even though a nonexhaustive enum may gain additional cases in the future, 
>> it's still useful for the compiler to diagnose that you forgot *known* cases.
>> 
>> You say that "switches over non-exhaustive enums should be uncommon", and 
>> this is true for many—perhaps most—non-exhaustive enums, but there is still 
>> a large class of non-exhaustive enums which need to be switched over. These 
>> are the ones I called "category 2" in my previous email in this thread. 
>> `SKPaymentTransactionState` is the example I previously used; others might 
>> include `Stream.Status` (if not exhaustive), `CLAuthorizationStatus`, 
>> `EKParticipantType`, `PKPaymentMethodType`, and `MKMapType`. Each of these 
>> could plausibly have more cases added; each has a good reason why you might 
>> switch over cases (such as display in a user interface); and each ought to 
>> be promptly updated when a new OS version introduces new cases. Without 
>> compiler assistance, those updates won't happen.
>> 
>> If we plan to add private cases in a future version of Swift, `future` may 
>> not be the best keyword. `unknown`, `invalid` (or `case #invalid`), etc. may 
>> be better.
>> 
>> 3. I am very skeptical of treating all enums as exhaustive if imported by 
>> `@testable import`. The only reason I can see not to do this is that forcing 
>> you to provide `default` might hide tests that need to be updated for new 
>> enum cases—but this is the exact problem that `future` is trying to solve. 
>> By contrast, treating them as non-exhaustive forces you to actually notice 
>> when an enum is published as nonexhaustive and consider whether that's the 
>> right approach.
>> 
>> None of these are showstoppers if left unaddressed, but I think the design 
>> would be better if we fixed them.
>> 
>>> • Is the problem being addressed significant enough to warrant a change 
>>> to Swift?
>> 
>> Yes. I have no idea how Swift programs currently behave when a future 
>> framework version adds a case, but I can't imagine they do anything good.
>> 
>>> • Does this proposal fit well with the feel and direction of Swift?
>> 
>> Yes, with the exception of conflating `default` and `future`, which removes 
>> useful correctness checks.
>> 
>>> • If you have used other languages or libraries with a similar feature, 
>>> how do you feel that this proposal compares to those?
>> 
>> I've experienced bugs in Objective-C caused by the compiler not knowing an 
>> enum might have additional, unknown cases. Debugging them sucked.
>> 
>>> • How much effort did you put into your review? A glance, a quick 
>>> reading, or an in-depth study?
>> 
>> I've participated in multiple rounds of discussion on this topic, and read 
>> the proposal top-to-bottom for this review.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> ___
>> 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 0192 - Non-Exhaustive Enums

[Vladimir.S via swift-evolution]

FWIW also +1 for @frozen
(and actually +1 for everything Brent said)

On 21.12.2017 14:28, Jonathan Hull via swift-evolution wrote:

+1 for @frozen


On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution 
 wrote:


On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
 wrote:

• What is your evaluation of the proposal?


I am pleased with the broad strokes of this design. I have quibbles with three 
areas:

1. The `@exhaustive` attribute may be confusing because the term doesn't 
suggest versioning. My best alternative suggestion is `@frozen`, which matches 
existing programming terminology: something that has been frozen will not be 
changed in the future.

2. I think we need some kind of `future` keyword in `switch` statements. Even 
though a nonexhaustive enum may gain additional cases in the future, it's still 
useful for the compiler to diagnose that you forgot *known* cases.

You say that "switches over non-exhaustive enums should be uncommon", and this is true 
for many—perhaps most—non-exhaustive enums, but there is still a large class of non-exhaustive 
enums which need to be switched over. These are the ones I called "category 2" in my 
previous email in this thread. `SKPaymentTransactionState` is the example I previously used; others 
might include `Stream.Status` (if not exhaustive), `CLAuthorizationStatus`, `EKParticipantType`, 
`PKPaymentMethodType`, and `MKMapType`. Each of these could plausibly have more cases added; each 
has a good reason why you might switch over cases (such as display in a user interface); and each 
ought to be promptly updated when a new OS version introduces new cases. Without compiler 
assistance, those updates won't happen.

If we plan to add private cases in a future version of Swift, `future` may not 
be the best keyword. `unknown`, `invalid` (or `case #invalid`), etc. may be 
better.

3. I am very skeptical of treating all enums as exhaustive if imported by 
`@testable import`. The only reason I can see not to do this is that forcing 
you to provide `default` might hide tests that need to be updated for new enum 
cases—but this is the exact problem that `future` is trying to solve. By 
contrast, treating them as non-exhaustive forces you to actually notice when an 
enum is published as nonexhaustive and consider whether that's the right 
approach.

None of these are showstoppers if left unaddressed, but I think the design 
would be better if we fixed them.


• Is the problem being addressed significant enough to warrant a change 
to Swift?


Yes. I have no idea how Swift programs currently behave when a future framework 
version adds a case, but I can't imagine they do anything good.


• Does this proposal fit well with the feel and direction of Swift?


Yes, with the exception of conflating `default` and `future`, which removes 
useful correctness checks.


• If you have used other languages or libraries with a similar feature, 
how do you feel that this proposal compares to those?


I've experienced bugs in Objective-C caused by the compiler not knowing an enum 
might have additional, unknown cases. Debugging them sucked.


• How much effort did you put into your review? A glance, a quick 
reading, or an in-depth study?


I've participated in multiple rounds of discussion on this topic, and read the 
proposal top-to-bottom for this review.

--
Brent Royal-Gordon
Architechies

___
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 0192 - Non-Exhaustive Enums

[Rod Brown via swift-evolution]

> On 20 Dec 2017, at 9:58 am, 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. I was involved in some of the earlier discussions and discussed the pros 
and cons of each way, tossed and turned, and to be honest, like “public vs 
open” I think this comes out to “it’s the best compromise”. 


We need to handle additional cases safely, and people need to think carefully 
as it will be a compatibility issue to leave new enum cases unhandled. This 
proposal sums this up well.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
Yes. This is an important change.

> Does this proposal fit well with the feel and direction of Swift?
> 
Feel? Not 100%, but this is a compromise for compatibility. Direction? Yes. It 
is in a direction to allow ABI compatibility, so yes.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
I’ve dealt with not handling extra cases in Obj-C, and handling the 
compatibility issues with current Swift code.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
Somewhere between a quick reading and a in-depth study. This was one of my 
bugbears, something I knew we needed to sort out and I’m glad Jordan picked it 
up. I was involved in the conversation, and churned through the issues there in 
the earlier discussions.
> 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] Evaluating the case of an enum with associated values as a bool

[Lustyik Tamás via swift-evolution]

There was a similar thread early this year which I tried to resurrect like
a month ago. In my reply I suggested freeing pattern matching from control
statements and allowing any pattern matching expression to be evaluated as
a boolean. Let me quote what I wrote there:

<< {
case success(T)
case failure
}

let r = Result.success(42)
let rs: [Result] = [.success(2), .success(3), .failure, .success(5),
.failure]

let simpleTest: Bool = (case .success = r)
let simpleFiltered: [Result] = rs.filter { case .success = $0 }

Now, we could take this even further and allow matching for subparts:

let subpartTest: Bool = (case .success(let v) = r, v < 100)
// --> true
let subpartFiltered: [Result] = rs.filter { case .success(let v) = $0,
v % 2 == 1 }
// --> [.success(3), .success(5)]

or perhaps with a more verbose syntax:

let subpartTest2: Bool = (case .success(let v) = r where v < 100)
let subpartFiltered2: [Result] = rs.filter { case .success(let v) = $0
where v % 2 == 1 }

I'm not familiar with the parsing challenges of the above suggestion but
these expressions don't look wildly different from what we already see in
currently supported pattern matching constructs.

QUOTE

So what do you think of this approach? To me it looks less clumsy than
generating "getXY"-style accessors.

Tamas



On Thu, Dec 21, 2017 at 1:50 AM, Ethan Diamond via swift-evolution <
swift-evolution@swift.org> wrote:

> It feels like it solves my current problem in a way that's almost as
> undesirable as the current solution. Say I have:
>
> Enum A {
>case x(String?)
>case y(String)
> }
>
> Right now I have code like this peppered throughout my code, which I think
> we can agree is pretty undesirable:
>
> if let case .x = value { return true } else { return false }
>
> I actually think that new syntax would be worse. It's not obvious what
> this does:
>
> if let string = value.getX() {
> return string != nil
> } else {
> return false
> }
>
> Even aside from readability, it strikes me as very weird that we have
> clean syntax for cases that ignore associated values inside of switch, if
> and guard statements, but outside of them we need to always write code
> around the associated value even when the associated values don't matter to
> what we're trying to do. I'm not going to pretend it's something I hit
> every day, but it's something I do *fairly* often, and it always feels like
> I'm fighting the language to do it.
>
> Having an isX() would be a big improvement, and I think we'd happily take
> it. That being said, any of these are the code I would ideally want to
> write:
>
> let a: A = .x("String")
>
> a.matches(.x) // true
> a.matches(.x(_)) // true
> a.matches(.x("Taco") // false
>
> or
>
> case(of: a) == .x // true (my personal favorite)
>
> or
>
> case a == .x // true
>
>
> On Wed, Dec 20, 2017 at 3:11 PM Chris Lattner  wrote:
>
>> On Dec 20, 2017, at 2:12 PM, Ethan Diamond 
>> wrote:
>>
>> Would that synthesize an isY() even though .Y has an associated value
>> there?
>>
>>
>> I’m not aware of a concrete design for this idea.  The details would
>> definitely need to be figured out, but I don’t see why a double optional is
>> itself a problem.
>>
>> -Chris
>>
>>
>> enum E {
>> case X
>> case Y(Int?)
>> }
>>
>> If I had to run that through getY() -> Int??, it still wouldn't be quite
>> what I was looking for with regards to intent. If you are planning an doing
>> an isY though, that would work for most cases where you're evaluating for a
>> given enum and know what it is beforehand. Even so that wouldn't work for a
>> case, for example, where I'm trying to see if two enums are the same case,
>> and don't necessarily care if they're equal.
>>
>> let value1 = E.Y(1)
>> let value2 = E.Y(2)
>>
>> value1 == value2 // false
>> value1 [is the same case as] value 2 // how do I get this?
>>
>> This would be useful, say, if I was trying to generate a diff of two
>> arrays of enums, which I occasionally do for table / collection views to
>> figure out inserts/removals/updates.
>>
>> I don't necessarily know if it's feasible, but it would be really great
>> to have something like a Case metatype, the same way we have type(of: ). It
>> would be great to have a case(of: ) that we can evaluate against the
>> shorthand like we do in switch statements.
>>
>> Ex:
>>
>> case(of: value1) == .Y // true
>> case(of: value1) == .X // false
>> case(of: value1) == case(of: value2) // true
>>
>>
>>
>> On Wed, Dec 20, 2017 at 1:31 PM Chris Lattner 
>> wrote:
>>
>>> In the past, we’ve discussed synthesizing predicate members onto enums.
>>> E.g. given:
>>>
>>> enum E {
>>>   case X
>>>   case Y(Int)
>>> }
>>>
>>> you’d get something like:
>>>
>>> extension E {
>>>   func isX() -> Bool { return self == .X }
>>>   func getY() -> Int? { … }
>>> }
>>>
>>> which would solve the client side of this nicely.
>>>
>>> -Chris
>>>
>>>
>>>
>>> On Dec 20, 2017, at 11:24 AM, 

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

[Jonathan Hull via swift-evolution]

+1 for @frozen

> On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
>>  wrote:
>> 
>>  • What is your evaluation of the proposal?
> 
> I am pleased with the broad strokes of this design. I have quibbles with 
> three areas:
> 
> 1. The `@exhaustive` attribute may be confusing because the term doesn't 
> suggest versioning. My best alternative suggestion is `@frozen`, which 
> matches existing programming terminology: something that has been frozen will 
> not be changed in the future.
> 
> 2. I think we need some kind of `future` keyword in `switch` statements. Even 
> though a nonexhaustive enum may gain additional cases in the future, it's 
> still useful for the compiler to diagnose that you forgot *known* cases.
> 
> You say that "switches over non-exhaustive enums should be uncommon", and 
> this is true for many—perhaps most—non-exhaustive enums, but there is still a 
> large class of non-exhaustive enums which need to be switched over. These are 
> the ones I called "category 2" in my previous email in this thread. 
> `SKPaymentTransactionState` is the example I previously used; others might 
> include `Stream.Status` (if not exhaustive), `CLAuthorizationStatus`, 
> `EKParticipantType`, `PKPaymentMethodType`, and `MKMapType`. Each of these 
> could plausibly have more cases added; each has a good reason why you might 
> switch over cases (such as display in a user interface); and each ought to be 
> promptly updated when a new OS version introduces new cases. Without compiler 
> assistance, those updates won't happen.
> 
> If we plan to add private cases in a future version of Swift, `future` may 
> not be the best keyword. `unknown`, `invalid` (or `case #invalid`), etc. may 
> be better.
> 
> 3. I am very skeptical of treating all enums as exhaustive if imported by 
> `@testable import`. The only reason I can see not to do this is that forcing 
> you to provide `default` might hide tests that need to be updated for new 
> enum cases—but this is the exact problem that `future` is trying to solve. By 
> contrast, treating them as non-exhaustive forces you to actually notice when 
> an enum is published as nonexhaustive and consider whether that's the right 
> approach.
> 
> None of these are showstoppers if left unaddressed, but I think the design 
> would be better if we fixed them.
> 
>>  • Is the problem being addressed significant enough to warrant a change 
>> to Swift?
> 
> Yes. I have no idea how Swift programs currently behave when a future 
> framework version adds a case, but I can't imagine they do anything good.
> 
>>  • Does this proposal fit well with the feel and direction of Swift?
> 
> Yes, with the exception of conflating `default` and `future`, which removes 
> useful correctness checks.
> 
>>  • If you have used other languages or libraries with a similar feature, 
>> how do you feel that this proposal compares to those?
> 
> I've experienced bugs in Objective-C caused by the compiler not knowing an 
> enum might have additional, unknown cases. Debugging them sucked.
> 
>>  • How much effort did you put into your review? A glance, a quick 
>> reading, or an in-depth study?
> 
> I've participated in multiple rounds of discussion on this topic, and read 
> the proposal top-to-bottom for this review.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> 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] Evaluating the case of an enum with associated values as a bool

[David Hart via swift-evolution]

> On 20 Dec 2017, at 20:24, Ethan Diamond via swift-evolution 
> > wrote:
> 
> Sorry all for attaching the original post to the Non-Exhaustive enums thread. 
> I"m moving it down to it's own thread. 
> 
> My understanding is I'm not allowed to write up a proposal unless I have the 
> time to implement it. Is that still true? This is a major pain point for me 
> to avoid having to write things like this:

All proposals need an implementation before they can go through the final 
review stage, but the proposal author doesn’t also have to be the implementor.
> if case .search = presenter.state { return true } else { return false }
> 
> Side note: Thanks Kevin, didn't know you could nest enums in switches like 
> that. Super helpful!
> 
> --
> I thought I would add another case that isn’t possible with current syntax 
> (so far as I’m aware).  You can’t negate the comparison to do something for 
> all cases except a particular case.  You have to have an empty if block and 
> use the else block, or have an empty case in a switch statement and use the 
> default.
> 
> enum Enum {
>   case a(param: String)
>   case b(param: String)
>   case c(param: String)
> }
> 
> let enumeration: Enum = .a(param: "Hi")
> 
> if !(case .a = enumeration) {
>   // Do something
> }
> 
> — Charles
> 
> > On Dec 20, 2017, at 9:55 AM, Kevin Nattinger via swift-evolution 
> >  > > wrote:
> > 
> > I agree this would be useful. At the moment I have to hack around it with 
> > things like `var isFoo: Bool { if case .foo = self …`* with cases I 
> > commonly need, but this is definitely a feature that has come up before and 
> > I support. It is potentially related to getting the values through an 
> > accessor, which has also come up several times.
> > 
> > Sidenote, your `switch` example is actually trivial with existing syntax:
> > 
> > switch enumeration {
> > case .a(.c(let param)): // or just .a(.c) if you don't need the value
> > print(param)
> > default:
> > break
> > }
> > 
> > I use this from time to time switching over, e.g., optional enums.
> > 
> > *: ugliest syntax ever, and it can't even be used as a standalone 
> > expression.
> > 
> > 
> >> On Dec 20, 2017, at 8:44 AM, Ethan Diamond via swift-evolution 
> >>  >>  
> >>  >> >> 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)

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
>