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

[Riley Testut via swift-evolution]

Actually, from the other email thread about this same topic (thank god forums 
are almost here), I see the proposed syntax “final switch” for what I referred 
to as “switch!”, which I prefer.

> On Dec 28, 2017, at 12:17 AM, Riley Testut via swift-evolution 
>  wrote:
> 
> -1.
> 
> I agree this is a problem, but I think this is the wrong solution. I think 
> the solution should be on the client side, not on the framework author’s side.
> 
> I would be fine if enums from imported modules are non-exhaustive, as long as 
> I can choose to treat them as exhaustive if I want to. And in that case, if a 
> new case is introduced, I think a fatal error is a reasonable result.
> 
> The proposed “switch!” command would do just this, and I think that is the 
> better answer for this. Adding an @exhaustive attribute doesn’t actually 
> prevent someone from adding a case anyway, which I think is a big (and not 
> really solvable) issue 路‍♂️
> 
> I know much has been said about this, but it’s just my 2c.
> 
>> On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> 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?
>>> 
>> 
>> -1
>> 
>> I would much prefer the solution proposed by Andrew Bennett in another 
>> thread which solves all problems very nicely including the testability of 
>> future cases by giving them a placeholder name:
>> 
>> From Andrew’s mail:
>>> 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.
>> 
>> i.e. Andrew’s idea is to introduce a placeholder case instead of marking the 
>> enum as exhaustive/non-exhaustive. This gives the future cases a handle to 
>> be switched on and to be tested against. Very elegant.
>> 
>>> Is the problem being addressed significant enough to warrant a change to 
>>> Swift?
>>> 
>> Yes, but the proposed solution is not as good as it should be, neglecting to 
>> provide compile-time errors if new cases are introduced.
>>> Does this proposal fit well with the feel and direction of Swift?
>>> 
>> No, due to its shortcomings.
>>> If you have used other languages or libraries with a similar feature, how 
>>> do you feel that this proposal compares to those?
>>> 
>> None, but see Andrew Bennett’s idea above.
>>> How much effort did you put into your review? A glance, a quick reading, or 
>>> an in-depth study?
>>> 
>> Followed most of the discussion and review threads.
>> 
>> -Thorsten
>> ___
>> 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

[Riley Testut via swift-evolution]

-1.

I agree this is a problem, but I think this is the wrong solution. I think the 
solution should be on the client side, not on the framework author’s side.

I would be fine if enums from imported modules are non-exhaustive, as long as I 
can choose to treat them as exhaustive if I want to. And in that case, if a new 
case is introduced, I think a fatal error is a reasonable result.

The proposed “switch!” command would do just this, and I think that is the 
better answer for this. Adding an @exhaustive attribute doesn’t actually 
prevent someone from adding a case anyway, which I think is a big (and not 
really solvable) issue 路‍♂️

I know much has been said about this, but it’s just my 2c.

> On Dec 27, 2017, at 9:42 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
> 
>> 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?
>> 
> 
> -1
> 
> I would much prefer the solution proposed by Andrew Bennett in another thread 
> which solves all problems very nicely including the testability of future 
> cases by giving them a placeholder name:
> 
> From Andrew’s mail:
>> 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.
> 
> i.e. Andrew’s idea is to introduce a placeholder case instead of marking the 
> enum as exhaustive/non-exhaustive. This gives the future cases a handle to be 
> switched on and to be tested against. Very elegant.
> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> 
> Yes, but the proposed solution is not as good as it should be, neglecting to 
> provide compile-time errors if new cases are introduced.
>> Does this proposal fit well with the feel and direction of Swift?
>> 
> No, due to its shortcomings.
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> 
> None, but see Andrew Bennett’s idea above.
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> 
> Followed most of the discussion and review threads.
> 
> -Thorsten
> ___
> 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] Why doesn't enum destructuring use guaranteed references?

[Félix Cloutier via swift-evolution]

Running this on my MBP with 10 as the parameter: 
https://gist.github.com/zneak/ae33bb970a08632cfb2925e2049f9e7a 
 

I get a runtime of about 10 seconds, 45% of which is spent in retain/release 
calls according to Instruments (!!), and at least half of that from Expr.count. 
Looking at the IR, Swift generously sprinkles retain/release calls through the 
outlined copy method:

`self` is retained at the beginning of `count`
The values that you get out of destructuring are retained
Of course, when you get `count` on these, they are retained again

Of course, Expr.count cannot modify itself or its subexpressions because the 
functions are not mutating; in fact, no function in that program can mutate an 
enum case. Why, then, is Swift retaining/releasing `self` and the values 
obtained from destructured patterns? They can't go away. Shouldn't we be 
getting guaranteed references instead of owning references?

That seems to hit pattern-matching-heavy programs with indirect cases pretty 
hard, and it's pretty frustrating because that seems to be about the nicest way 
to write this program, and there's no workaround from the developer's 
perspective. I don't think that this is a fatal flaw of refcounting, but unless 
I'm missing something, that's sub-par behavior.

Félix___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Cheyo Jimenez via swift-evolution]

> On Dec 25, 2017, at 9:14 AM, Cheyo Jimenez via swift-evolution 
>  wrote:
> 
> 
> 
>> On Dec 22, 2017, at 8:49 AM, Cheyo Jose Jimenez  wrote:
>> 
>> 
>> 
>>> On Dec 20, 2017, at 11:12 PM, Cheyo Jimenez  wrote:
>>> 
>>> 
>>> 
 On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution 
  wrote:
 
 The review of "SE 0192 - Non-Exhaustive Enums" begins now and runs through 
 January 3, 2018.
 
 The proposal is available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
 Reviews are an important part of the Swift evolution process. All review 
 feedback should be sent to the swift-evolution mailing list at:
 
 https://lists.swift.org/mailman/listinfo/swift-evolution
 or, if you would like to keep your feedback private, directly to the 
 review manager. 
 
 When replying, please try to keep the proposal link at the top of the 
 message:
 
 Proposal link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
 ...
 Reply text
 ...
 Other replies
 What goes into a review of a proposal?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. 
 
 When reviewing a proposal, here are some questions to consider:
 
 What is your evaluation of the proposal?
 
>>> +1 except for the name. @frozenExposed @fixedMembers @frozenMembers. 
>>> preferably something that aligns with the other notion of not being able to 
>>> add public members to structs. This will help treat structs with static 
>>> members in the same way which would be ideal.  I don't think enums should 
>>> have their own attitude.
 Is the problem being addressed significant enough to warrant a change to 
 Swift?
 
>>> don't know. im not a library author. ill defer to other library authors. 
>> 
>> I want to revise my review here. While I am not a library author I am a 
>> library consumer. 
>> 
>> Having the ability treat a non exhaustive enum as exhaustive should be 
>> introduced with this. I like the idea of a 
>> `final switch`
>> 
>> I think it communicate clearly that I want this to be treated as exhaustive 
>> even if it is already exhaustive. Having something like future, unknowns 
>> would be weird to me. 
>> 
>> Another option would be being able to cast a enum as exhaustive. I am not 
>> sure how that would work. I do not like switch!  
> 
> Preferably I’d like to say: 
> 
> switch (@exhaustive x){...}
> 
> Would this be allowed?
> 
> let @exhaustive myEnum=  x
> 
> typealias  @exhaustive Y = X
> 
> if let @exhaustive x = x {
>  switch x {...} // exhaustive here. 
> }
> 
> Could this be addressed in the proposal? 

I would also expect case _  to only match known cases since _ acts like a wild 
char. 

switch x { // x is non-exhaustive here. 
  case _ : fatalError("compile time error when missing cases ") // known cases 
at compile time 
  default: fatalError("runtime error when missing cases") // unknown cases. 
}

It makes sense for default and case _ to do the same thing for exhaustive enums 
but not for non exhaustive. 

Could this be addressed in the proposal too?  Thanks in advance. 


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

Re: [swift-evolution] namespacing protocols to other types

[Karl Wagner via swift-evolution]

Yeah I wrote that proposal. I eventually stripped it down to just disallow all 
capturing, but it was still not selected by the core team for review ¯\_(ツ)_/¯

As for capturing semantics, once you start working through use-cases, it’s 
becomes clear that it's going to require generalised existentials. Otherwise, 
how would you use a Generic.P?

struct Generic {
protocol P { func f() -> T }

var object: P // uh-oh! ‘Generic protocol can only be used as a generic 
parameter constraint'
}

So, you would need to add a generic parameter to actually use P from within 
Generic, which of course limits you to a single concrete type of P:

struct Generic where TypeOfP: Self.P {  // Could this even 
work? What if P captures TypeOfP?
protocol P { /* … */ }
var object: TypeOfP
}

Which is just yucky.

Ideally, the type of ‘object’ should be ‘Any’, to express 
that it can be any conforming type with the appropriate constraints. You 
wouldn’t need to write that all out; we could infer that capturing is 
equivalent to a same-type constraint (or perhaps one of these “generalised 
supertype constraints” that were pitched recently). But we can’t express those 
kinds of existentials everywhere in the type-system today, so most examples of 
capturing fall down pretty quickly.

- Karl

> On 25. Dec 2017, at 03:56, Slava Pestov via swift-evolution 
>  wrote:
> 
> There was a proposal to allow protocols to be nested inside types at one 
> point but it didn’t move forward.
> 
> Basically, if the outer type is a non-generic class, struct or enum, there’s 
> no conceptual difficulty at all.
> 
> If the outer type is a generic type or another protocol, you have a problem 
> where the inner protocol can reference generic parameters or associated types 
> of the outer type. This would either have to be banned, or we would need to 
> come up with coherent semantics for it:
> 
> struct Generic {
>  protocol P {
>func f() -> T
>  }
> }
> 
> struct Conforms : Generic.P {
>  func f() -> Int { … } // Like this?
> }
> 
> let c = Conforms()
> c is Generic.P // is this false? Ie, are Generic.P and 
> Generic.P different protocols?
> 
> Slava
> 
>> On Dec 24, 2017, at 6:53 PM, Kelvin Ma via swift-evolution 
>>  wrote:
>> 
>> is there a reason why it’s not allowed to nest a protocol declaration inside 
>> another type?
>> ___
>> 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

[Thorsten Seitz via swift-evolution]

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

-1

I would much prefer the solution proposed by Andrew Bennett in another thread 
which solves all problems very nicely including the testability of future cases 
by giving them a placeholder name:

>From Andrew’s mail:
> 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.

i.e. Andrew’s idea is to introduce a placeholder case instead of marking the 
enum as exhaustive/non-exhaustive. This gives the future cases a handle to be 
switched on and to be tested against. Very elegant.

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
Yes, but the proposed solution is not as good as it should be, neglecting to 
provide compile-time errors if new cases are introduced.
> Does this proposal fit well with the feel and direction of Swift?
> 
No, due to its shortcomings.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
None, but see Andrew Bennett’s idea above.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
Followed most of the discussion and review threads.

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

[Zach Waldowski via swift-evolution]

Sorry to glomm on to my own comments:

I think there’s a lot of reasonable push-back to requiring a default
case on non-exhaustive enums. I personally don’t want to see a “future
case” because I think it’s mystery-meat. However, in the happy path, as
a developer I do want *some* notification by the compiler that I may
need to handle a new case, even if my code is already in the wild
handling the case through a default. To fulfill Swift’s safety and
stability goals, it  needs to both avoid creating suddenly invalid code
at compile time and  avoid UB at runtime. The community should take note
that this all a bit of cutting  a Gordian knot on the part of the
language, but it's worthwhile to avoid adding cruft and bugs.
Sincerely,
  Zachary Waldowski
  z...@waldowski.me

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

Re: [swift-evolution] Enums and Source Compatibility

[Thorsten Seitz via swift-evolution]

> Am 21.12.2017 um 23:48 schrieb 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.

This is an extremely elegant solution which seems to solve all problems very 
nicely!!
Yes, instead of marking the enum as non-exhaustive let’s just add a placeholder 
case for future cases.
I’m very much in favor of this.

-Thorsten



> 
> Thanks,
> Andrew
> 
> On Tue, Oct 3, 2017 at 8:10 AM, 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.
> - 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 
>> > 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 

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

[Zach Waldowski via swift-evolution]

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

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


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


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

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

[Thorsten Seitz via swift-evolution]

Hi all,

I am very much in favor of ‘switch x { … unknown: … }’ to express that I am 
expecting the cases to be complete at compile time so that I get notified when 
compiling against a newer version of the library where the enum has been 
extended.

I consider not being able to test this a minor problem compared with not 
getting informed when new cases have been added. 

-Thorsten


> Am 24.12.2017 um 01:29 schrieb Slava Pestov via swift-evolution 
> :
> 
> Hi Thomas,
> 
> I see what you mean now. I think in this case I would prefer to just spell 
> this as ‘switch x { … unknown: … }’ vs ‘switch x { … default: … }’. But yes, 
> a few people have signaled support for such a feature and I think it’s worth 
> discussing.
> 
> Slava
> 
>> On Dec 23, 2017, at 4:27 PM, Thomas Roughton > > wrote:
>> 
>> Hi Slava,
>> 
>> I think we may be referring to different things. For whatever it’s worth, I 
>> agree with your reasoning on all the points you brought up. I also don’t 
>> think having a 'default: fatalError()’ case is a good idea because then a 
>> library change can cause crashes in a running version of an application.
>> 
>> What I mean by some sort of ‘complete switch’ statement is that it would be 
>> compiled as per a normal ‘switch’ but error at compile time if it’s not 
>> complete against the known set of cases as compile time. Assuming an enum 
>> with known cases [a, b] at compile time,
>> 
>> switch nonExhaustiveEnum {
>>  case a:
>>  print(“a”)
>>  case b:
>>  print(“b”)
>>  default:
>>  break
>> }
>> 
>> would be exactly equivalent to:
>> 
>> complete switch nonExhaustiveEnum {
>>  case a:
>>  print(“a”)
>>  case b:
>>  print(“b”)
>>  unknown:  // the ‘unknown’ case would only be required for 
>> non-exhaustive enums
>>  break
>> }
>> 
>> where the keywords ‘complete’ and ‘unknown’ are up for debate. If, however, 
>> the programmer wrote:
>> 
>> complete switch nonExhaustiveEnum {
>>  case a:
>>  print(“a”)
>>  unknown:
>>  break
>> }
>> 
>> the compiler would give an error that there are unhandled cases in the 
>> switch statement, whereas
>> 
>> switch nonExhaustiveEnum {
>>  case a:
>>  print(“a”)
>>  default:
>>  break
>> }
>> 
>> would compile without issue. If a user didn’t know about the existence of 
>> the ‘complete switch’ construct, they could just use normal ‘switch’ 
>> statements and miss out on the completeness checking.
>> 
>> Thomas
>> 
>>> On 24/12/2017, at 1:15 PM, Slava Pestov >> > wrote:
>>> 
>>> 
>>> 
 On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution 
 > wrote:
 
 
 On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution 
 > wrote:
> 
> What are your thoughts on `final switch` as a way to treat any enum as 
> exhaustible?
> https://dlang.org/spec/statement.html#FinalSwitchStatement 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
 
 I’d be very much in favour of this (qualms about the naming of the ‘final’ 
 keyword aside - ‘complete’ or ‘exhaustive’ reads better to me). 
 
 Looking back at the proposal, I noticed that something similar was 
 mentioned that I earlier missed. In the proposal, it says:
 
> However, this results in some of your code being impossible to test, 
> since you can't write a test that passes an unknown value to this switch.
 
 Is that strictly true? Would it be theoretically possible for the compiler 
 to emit or make accessible a special ‘test’ case for non-exhaustive enums 
 that can only be used in test modules or e.g. by a 
 ‘EnumName(testCaseNamed:)’, constructor? There is  potential for abuse 
 there but it would address that particular issue. 
 
 Regardless, I still feel something like a ‘final switch’ is necessary if 
 this proposal is introduced, and that it fits with the ‘progressive 
 disclosure’ notion; once you learn this keyword you have a means to check 
 for completeness, but people unaware of it could just use a ‘default’ case 
 as per usual and not be concerned with exhaustiveness checking. 
>>> 
>>> My general philosophy with syntax sugar is that it should do more than just 
>>> remove a constant number of tokens. Basically you’re saying that
>>> 
>>> final switch x {}
>>> 
>>> just expands to
>>> 
>>> 

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

[Zach Waldowski via swift-evolution]

On Tue, Dec 19, 2017, at 5:58 PM, Ted Kremenek wrote:
>  * What is your evaluation of the proposal?
+1.

I strongly prefer all additions to service ABI follow progressive
disclosure, but it’s not reason alone to make the annotation be mystery
meat. Like the inlining proposal, the spelling needs some consideration
by the core team to provide an ergonomic through-line through the
language. I liked reusing `final` way back when the proposal first came
up, but that ship appears to have sailed. If an annotation is our
preference, I do like `@frozen` if we see it come up in interesting ways
elsewhere.
>  * Is the problem being addressed significant enough to warrant a
>change to Swift?
I see this proposal and its discussion mostly as prevarication on the
spelling and the default behavior. Those aside, it solves a bug, so bar-
none something must be done. In a perfect world, no annotation or
closed/open would be needed, but this is unrealistic, and a solution
that involves compile-time diagnostics over runtime failures is
preferable.
>  * Does this proposal fit well with the feel and direction of Swift?
ABI stability is a high-level goal, and this fits within it.

The Core Team and Apple could do a better job with messaging its
compatibility impact. Though I understand it now, changing a feature’s
behavior is indeed surprising at this point. My understanding is that
nothing will change for creating enums in the single target happy path,
with a stretch goal being to extend that to all  source targets that
produce a single (in Apple terminology) bundle. I know y’all can’t
discuss future dev tools directions, but it may have helped us to know
the plan for what constitutes the compiler “seeing” an enum’s source to
make a resilience decision.
>  * If you have used other languages or libraries with a similar
>feature, how do you feel that this proposal compares to those?
I’m most familiar if the impact of this problem on ObjC, where it was
only really solved for Apple. We’re forging new territory for solving
this at the ABI level for any binary module, so some uncertainty is to
be expected.
>  * How much effort did you put into your review? A glance, a quick
>reading, or an in-depth study?
I’ve followed the proposal in depth since its early stages.

Sincerely,
  Zachary Waldowski
  z...@waldowski.me
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution