[swift-evolution] Help
Michael Tan
tan.michael at mac.com
Wed Dec 20 12:04:53 CST 2017
Sent from my iPhone
> On 20 Dec 2017, at 5:57 PM, swift-evolution-request at swift.org wrote:
>
> Send swift-evolution mailing list submissions to
> swift-evolution at swift.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.swift.org/mailman/listinfo/swift-evolution
> or, via email, send a message with subject or body 'help' to
> swift-evolution-request at swift.org
>
> You can reach the person managing the list at
> swift-evolution-owner at swift.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swift-evolution digest..."
>
>
> Today's Topics:
>
> 1. Re: [Accepted with revisions] SE-0187 “Introduce
> Sequence.filterMap(_:)” (swift at lng.la)
> 2. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)” (Brent Royal-Gordon)
> 3. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)” (Xiaodi Wu)
> 4. Re: Add transformers to Codable (Tony Parker)
> 5. [Review] SE 0192 - Non-Exhaustive Enums (Ted Kremenek)
> 6. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Kevin Ballard)
> 7. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)” (Dave Abrahams)
> 8. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)”
> (Nevin Brackett-Rozinsky)
> 9. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)” (Dave Abrahams)
> 10. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Xiaodi Wu)
> 11. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)” (swift at lng.la)
> 12. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Slava Pestov)
> 13. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Kevin Ballard)
> 14. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Slava Pestov)
> 15. Re: [swift-evolution-announce] [Accepted with revisions]
> SE-0187 “Introduce Sequence.filterMap(_:)” (Paul Cantrell)
> 16. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Howard Lovatt)
> 17. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Xiaodi Wu)
> 18. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Howard Lovatt)
> 19. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Xiaodi Wu)
> 20. Re: Proposal: Introduce User-defined "Dynamic Member Lookup"
> Types (Douglas Gregor)
> 21. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Sebastian Hagedorn)
> 22. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Jérôme Duquennoy)
> 23. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Brent Royal-Gordon)
> 24. Re: [Review] SE 0192 - Non-Exhaustive Enums (Letanyan Arumugam)
> 25. Re: [swift-evolution-announce] [Review] SE 0192 -
> Non-Exhaustive Enums (Sebastian Hagedorn)
> 26. Re: [Review] SE 0192 - Non-Exhaustive Enums (Karl Wagner)
> 27. Re: [Proposal] Random Unification (Jens Persson)
> 28. Re: [Review] SE 0192 - Non-Exhaustive Enums (Karl Wagner)
> 29. [Pitch] @static imports (Karl Wagner)
> 30. Re: [Review] SE 0192 - Non-Exhaustive Enums (Vladimir.S)
> 31. Re: [Proposal] Random Unification (Xiaodi Wu)
> 32. Evaluating the case of an enum with associated values as a
> bool (Ethan Diamond)
> 33. Re: [Review] SE 0192 - Non-Exhaustive Enums (Dave DeLong)
> 34. Re: Evaluating the case of an enum with associated values as
> a bool (Kevin Nattinger)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 Dec 2017 11:15:26 -0800
> From: swift at lng.la
> To: Swift Evolution <swift-evolution at swift.org>, John McCall
> <rjmccall at apple.com>
> Subject: Re: [swift-evolution] [Accepted with revisions] SE-0187
> “Introduce Sequence.filterMap(_:)”
> Message-ID: <ec9058cc-ea59-4e2a-b556-5e6584e049a9 at Spark>
> Content-Type: text/plain; charset="utf-8"
>
> Happy to hear that we went in this direction! Looking forward to the compact method as well.
>
> Jarod
>
>> On Dec 19, 2017, 08:56 -0800, John McCall via swift-evolution <swift-evolution at swift.org>, wrote:
>> Hi, Swift community! I apologize for the delay in reporting our decision here; between one holiday and the other, it took awhile for the core team to assemble a quorum to talk through this.
>>
>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
>>
>> The second review of SE-0187 “Introduce Sequence.filterMap(_:)” ran from November 15...20, 2017. The result of the first review was consensus to rename the method, and the purpose of the second review was to get more specific feedback on what the new name should be.
>>
>> "filterMap" is a name with some precedent in other programming languages, especially functional ones, but some people felt strongly that the name was misleading because, as a combined operation, it wasn't quite a filter or a map. Of the alternatives, the one with the strongest support seemed to be "compactMap", which builds on the precedent of "compact", an operation from other languages (notably Ruby) which returns a copy of the input without nil values. Swift does not currently have such an operation, and in fact it is not currently possible to express it; nonetheless, the core team agrees that it would be a reasonable operation to add, and that "compactMap" is a good name for the operation.
>>
>> 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.
>>
>> Thank you all for your continued contributions to making Swift a better language.
>>
>> John McCall
>> Review Manager
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/38ea7150/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 Dec 2017 14:08:51 -0800
> From: Brent Royal-Gordon <brent at architechies.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID: <B8B171AC-74B0-476E-B502-FB224EE24248 at architechies.com>
> Content-Type: text/plain; charset="utf-8"
>
>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com> 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.
>
> --
> Brent Royal-Gordon
> Architechies
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/9d6c49c9/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 19 Dec 2017 22:28:14 +0000
> From: Xiaodi Wu <xiaodi.wu at gmail.com>
> To: Brent Royal-Gordon <brent at architechies.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID:
> <CAGY80u=7cJdi3n9Kx+maQZwZ180E-rLC1-P+f6prPxjVUDzY1g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <
> swift-evolution at swift.org> wrote:
>
>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com> 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.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/4f982533/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 19 Dec 2017 14:38:12 -0800
> From: Tony Parker <anthony.parker at apple.com>
> To: Arsen Gasparyan <to.arsen.gasparyan at gmail.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] Add transformers to Codable
> Message-ID: <266B13E5-E31A-4EE1-9EDA-5942BE9C7A37 at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Arsen,
>
> What’s the difference between providing a method that takes a transformable object on the keyed container protocol and just transforming it yourself before you encode it?
>
> - Tony
>
>> On Dec 18, 2017, at 8:51 AM, Arsen Gasparyan via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Hello everyone,
>>
>> I’m suggesting to add a new way to encode/decode JSON properties for relevantly complex data formats such as regular expressions, well-known text, hex colours, custom date formats.
>>
>> The problem:
>>
>> Image you have a struct called House
>>
>> struct House {
>> let color: UIColor
>> }
>>
>> and it has a properly called color and the color represented in JSON as hex value (#ffffff). Currently to make it working you have to extract the underline value (string with a hex value) and then try to make a UIColor from it. It works but it makes you to copy/past a lot of code and it leads to problems. Also it shifts focus from what to decode to how to decode.
>>
>> The suggested solution:
>>
>> I suggest that we have to introduce protocols for classes that will encapsulate transformation from a source data type to a destination data type. The source data types are all existing data that support of decoding.
>>
>> We will provide only protocols (one for decoding and one for encoding) and users will be able to create transformers for their own data types.
>>
>> The implementation:
>>
>> The implementation is fairly easy. We only need introduce two protocols (encoding/decoding) and add a method to KeyedEncodingContainerProtocol that will accept a key and a transformer. In the method we will extract source data from JSON and then will ask the transformer to try to convert it to the desire data type.
>>
>> Example of the decoding protocol:
>>
>> protocol DecodingTransformer {
>> associatedtype Input: Decodable
>> associatedtype Output
>> func transform(_ decoded: Input) throws -> Output
>> }
>>
>>
>> Inspired by: https://github.com/Hearst-DD/ObjectMapper#custom-transforms <https://github.com/Hearst-DD/ObjectMapper#custom-transforms>
>>
>> Cheers,
>> Arsen
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/5731b401/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 19 Dec 2017 14:58:06 -0800
> From: Ted Kremenek <kremenek at apple.com>
> To: Swift Evolution <swift-evolution at swift.org>
> Subject: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
> Message-ID: <1E48068D-CF8F-420E-ADAE-BB7ABEA9A1B5 at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/ac089924/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 19 Dec 2017 15:31:01 -0800
> From: Kevin Ballard <kevin at sb.org>
> To: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <EF76C90D-CF09-41CA-A47E-8E157B6413DD at sb.org>
> Content-Type: text/plain; charset="utf-8"
>
>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek <kremenek at apple.com> wrote:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md <https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md>
>> What is your evaluation of the proposal?
>>
>
> Overall I like it, but I have some issues.
>
> I’m not completely sold yet on the idea that public enums should be non-exhaustive by default, as I believe every single public enum I’ve ever written definitely wants to be exhaustive. I’m tempted to say that enums exposed by frameworks that need to maintain future-compatibility (such as Apple’s frameworks) want non-exhaustive by default, but enums exposed by third-party frameworks that follow semantic versioning are likely to want exhaustive by default.
>
> In fact, this brings to mind another difference between enums in Apple frameworks and enums in third-party Swift frameworks, which is the former is exclusively C-compatible enums whereas the latter is going to have a lot of enums that carry associated values. I have no data to support this but I’m inclined to think that it’s more likely for C-compatible enums to want to be non-exhaustive than it is for enums carrying associated values to want to be non-exhaustive.
>
> So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).
>
> --
>
> I don’t like that modules using @testable imports treat all enums as exhaustive. I can see why you want to do that, but being forced to handle non-exhaustive enums in unit tests seems like a valuable guard against accidentally publishing non-exhaustive enums that should be exhaustive.
>
> --
>
> I’m really not a fan of using a ‘default’ case in non-exhaustive enums. This means that if new cases are added, the compiler can’t help me find my switches. I’d really like to have an alternative way of saying “here’s how to behave in the event of an unknown enum case” without also making that a catch-all for unspecified-but-known cases. You already brought up this issue in the alternatives section, where you stated
>
>> Ultimately I decided not to include this in the proposal with the expectation is that switches over non-exhaustive enums should be uncommon.
>
>
> But since non-exhaustive enums will be the default, I think this _will_ become quite common, if for no other reason than you’re using a library written by someone who forgot to mark enums as @exhaustive that really should be.
>
> Regarding the comment that a ‘future’ case is impossible to test, so is a ‘default’ case on a switch that is otherwise exhaustive. In the latter you can test it by commenting out one of your existing cases. But you can do that with ‘future’ too, just by renaming it to ‘default’ first.
>
> --
>
> In the “Use-side” section it says that a switch without a default case will produce a warning in Swift 4 mode. But in Swift 4 mode all enums are exhaustive by default and the @exhaustive annotation does nothing. These two things can’t both be true or else Swift 4 mode will emit warnings on switches over enums that are very clearly supposed to be exhaustive enums.
>> 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
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>
> A quick reading, followed by a few re-readings as I composed this email.
>
> -Kevin Ballard
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/eea3bd6e/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 19 Dec 2017 15:42:52 -0800
> From: Dave Abrahams <dabrahams at apple.com>
> To: Xiaodi Wu <xiaodi.wu at gmail.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID: <D83A44DB-3C1E-4BEB-83DD-C92F9A41E1B7 at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
>> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> 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).
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/b40ca000/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 19 Dec 2017 18:52:35 -0500
> From: Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com>
> To: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID:
> <CAK9u92Ov45OYi=_xBwGaQ36sMAi3KCh8Xb+ytyFnpzCTGR4rdA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> If we’re bikeshedding the verb tense then “compactMap” sounds right to me,
> and adding “ing” would be needlessly verbose.
>
> For the non-mapping version, I’d lean toward “compacted”. However, we could
> also postpone the debate over its spelling until such time as we are
> actually ready to introduce it.
>
> Nevin
>
>
>
> On Tue, Dec 19, 2017 at 6:42 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>>
>> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> 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 <
>> swift-evolution at swift.org> wrote:
>>
>>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com> 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).
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/04d4d04a/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Tue, 19 Dec 2017 16:02:19 -0800
> From: Dave Abrahams <dabrahams at apple.com>
> To: Dave Abrahams <dabrahams at apple.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID: <46F2363F-C7B9-4CEB-8424-109752CC1E68 at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
>> On Dec 19, 2017, at 3:42 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>>
>>> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> 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).
>
> meh, on second though, "map" is already right there. I'm ambivalent now; sorry I weighed in.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/d3fb78d3/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 19 Dec 2017 19:04:56 -0500
> From: Xiaodi Wu <xiaodi.wu at gmail.com>
> To: Kevin Ballard <kevin at sb.org>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID:
> <CAGY80uk6aKDtFefoj2LiVJbuxqPxozYPjdqBO4D66Hgmj_E_eA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Dec 19, 2017 at 6:31 PM, Kevin Ballard via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek <kremenek at apple.com> wrote:
>>
>> https://github.com/apple/swift-evolution/blob/master/
>> proposals/0192-non-exhaustive-enums.md
>>
>>
>> -
>>
>> What is your evaluation of the proposal?
>>
>> Overall I like it, but I have some issues.
>>
>> I’m not completely sold yet on the idea that public enums should be
>> non-exhaustive by default, as I believe every single public enum I’ve ever
>> written definitely wants to be exhaustive. I’m tempted to say that enums
>> exposed by frameworks that need to maintain future-compatibility (such as
>> Apple’s frameworks) want non-exhaustive by default, but enums exposed by
>> third-party frameworks that follow semantic versioning are likely to want
>> exhaustive by default.
>>
>> In fact, this brings to mind another difference between enums in Apple
>> frameworks and enums in third-party Swift frameworks, which is the former
>> is exclusively C-compatible enums whereas the latter is going to have a lot
>> of enums that carry associated values. I have no data to support this but
>> I’m inclined to think that it’s more likely for C-compatible enums to want
>> to be non-exhaustive than it is for enums carrying associated values to
>> want to be non-exhaustive.
>>
>> So I guess I’m saying, I want more thought put on the topic of whether
>> enums defined in Swift should actually default to non-exhaustive, and I’m
>> now leaning towards the idea that they should remain exhaustive (but Obj-C
>> enums will still default to non-exhaustive).
>>
>
> I think the proposal represents a very good summary of the pros and cons of
> each approach. At the pre-proposal stage, all possible solutions (there are
> only three: no default, default to exhaustive, or default to nonexhaustive)
> were thoroughly explored, and the proposal as revised here represents a
> thoughtful synthesis of the conversation and has a good justification for
> the default proposed. I highly doubt that any more back-and-forth on this
> will surface new arguments not already covered.
>
>
>> --
>>
>> I don’t like that modules using @testable imports treat all enums as
>> exhaustive. I can see why you want to do that, but being forced to handle
>> non-exhaustive enums in unit tests seems like a valuable guard against
>> accidentally publishing non-exhaustive enums that should be exhaustive.
>>
>
> On the contrary, I think that the proposal's behavior for `@testable` is
> fully consistent and the best solution possible. It preserves the behavior
> that `@testable` imports are treated as though internal, and it allows for
> unit tests to have compile-time errors when unexpected cases are added. Any
> time you want to test nonexhaustive behavior, you can import without
> `@testable`.
>
> --
>>
>> I’m really not a fan of using a ‘default’ case in non-exhaustive enums.
>> This means that if new cases are added, the compiler can’t help me find my
>> switches. I’d really like to have an alternative way of saying “here’s how
>> to behave in the event of an unknown enum case” without also making that a
>> catch-all for unspecified-but-known cases. You already brought up this
>> issue in the alternatives section, where you stated
>>
>> Ultimately I decided not to include this in the proposal with the
>> expectation is that switches over non-exhaustive enums should be uncommon.
>>
>>
>> But since non-exhaustive enums will be the default, I think this _will_
>> become quite common, if for no other reason than you’re using a library
>> written by someone who forgot to mark enums as @exhaustive that really
>> should be.
>>
>> Regarding the comment that a ‘future’ case is impossible to test, so is a
>> ‘default’ case on a switch that is otherwise exhaustive. In the latter you
>> can test it by commenting out one of your existing cases. But you can do
>> that with ‘future’ too, just by renaming it to ‘default’ first.
>>
>
> This, too, I think, has been discussed quite thoroughly, and I think the
> proposal synthesizes the discussion and presents the best possible solution.
>
>
>> In the “Use-side” section it says that a switch without a default case
>> will produce a warning in Swift 4 mode. But in Swift 4 mode all enums are
>> exhaustive by default and the @exhaustive annotation does nothing. These
>> two things can’t both be true or else Swift 4 mode will emit warnings on
>> switches over enums that are very clearly supposed to be exhaustive enums.
>>
>
> This is curious. I wonder if C enums will be nonexhaustive in both Swift 4
> and 5 mode, thereby triggering such warnings.
>
>>
>> -
>>
>> 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
>>
>>
>> -
>>
>> How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>>
>> A quick reading, followed by a few re-readings as I composed this email.
>>
>> -Kevin Ballard
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/53ec81a4/attachment-0001.html>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 19 Dec 2017 16:10:12 -0800
> From: swift at lng.la
> To: swift-evolution <swift-evolution at swift.org>, Nevin
> Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID: <46b3c777-95ae-4d51-ae05-1df2c8ea5a17 at Spark>
> Content-Type: text/plain; charset="utf-8"
>
> I don't think anybody wants a big discussion out of this, but if there's a chance that the name will be further revised, then I agree with Nevin, the solo "compacted" is a more appropriate term than "compacting" here. Compacting needs an grammatical object to apply to, so if we wanted to use that form, "compactingElements" would be the proper way to phrase it.
>
> "compactingMap" works, because the map operation is being compacted. But "compactedMap" also works, because it's a compacted form of the map operation.
>
> So if we want to revise the naming, I would suggest "compacted" and "compactedMap". But I think the accepted naming is fine as well, and we should avoid "compacting".
>
> Jarod
>
>> On Dec 19, 2017, 15:52 -0800, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org>, wrote:
>> If we’re bikeshedding the verb tense then “compactMap” sounds right to me, and adding “ing” would be needlessly verbose.
>>
>> For the non-mapping version, I’d lean toward “compacted”. However, we could also postpone the debate over its spelling until such time as we are actually ready to introduce it.
>>
>> Nevin
>>
>>
>>
>>>> On Tue, Dec 19, 2017 at 6:42 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>>
>>>>
>>>>> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> wrote:
>>>>>>>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com> 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).
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/bddf2a6f/attachment-0001.html>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 19 Dec 2017 17:35:14 -0800
> From: Slava Pestov <spestov at apple.com>
> To: Kevin Ballard <kevin at sb.org>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <3B55CD38-F1EC-4B4E-854D-55646F3BAD1B at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).
>
> This would introduce an inconsistency between enums and structs. Structs will not be fixed-contents by default (there’s a proposal coming for that), which means you will be able to add stored properties after the fact. For this reason it makes more sense to me to also make enums non-exhaustive by default so that new cases can be added.
>
> Slava
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/fd9d2499/attachment-0001.html>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 19 Dec 2017 18:42:37 -0800
> From: Kevin Ballard <kevin at sb.org>
> To: Slava Pestov <spestov at apple.com>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <0F077032-267A-4804-90D8-1DF1EF62DC30 at sb.org>
> Content-Type: text/plain; charset="utf-8"
>
> Isn’t this going to turn both structs and non-C-like enums into types that need to be auto-boxed (as the client won’t be able to rely on knowing the fixed size anymore)? This seems like a performance hazard.
>
> -Kevin Ballard
>
>> On Dec 19, 2017, at 5:35 PM, Slava Pestov <spestov at apple.com> wrote:
>>
>>
>>
>>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).
>>
>> This would introduce an inconsistency between enums and structs. Structs will not be fixed-contents by default (there’s a proposal coming for that), which means you will be able to add stored properties after the fact. For this reason it makes more sense to me to also make enums non-exhaustive by default so that new cases can be added.
>>
>> Slava
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/b581f132/attachment-0001.html>
>
> ------------------------------
>
> Message: 14
> Date: Tue, 19 Dec 2017 18:44:49 -0800
> From: Slava Pestov <spestov at apple.com>
> To: Kevin Ballard <kevin at sb.org>
> Cc: Chris Lattner via swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <B4E3C85F-AE61-43DB-9EC2-D50D49527929 at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
> They would not be boxed, but there would be additional indirection required at runtime, using the same mechanism currently used for unspecialized generics.
>
> Slava
>
>> On Dec 19, 2017, at 6:42 PM, Kevin Ballard <kevin at sb.org> wrote:
>>
>> Isn’t this going to turn both structs and non-C-like enums into types that need to be auto-boxed (as the client won’t be able to rely on knowing the fixed size anymore)? This seems like a performance hazard.
>>
>> -Kevin Ballard
>>
>>> On Dec 19, 2017, at 5:35 PM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>>>
>>>
>>>
>>>> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>> So I guess I’m saying, I want more thought put on the topic of whether enums defined in Swift should actually default to non-exhaustive, and I’m now leaning towards the idea that they should remain exhaustive (but Obj-C enums will still default to non-exhaustive).
>>>
>>> This would introduce an inconsistency between enums and structs. Structs will not be fixed-contents by default (there’s a proposal coming for that), which means you will be able to add stored properties after the fact. For this reason it makes more sense to me to also make enums non-exhaustive by default so that new cases can be added.
>>>
>>> Slava
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/454ea4dd/attachment-0001.html>
>
> ------------------------------
>
> Message: 15
> Date: Tue, 19 Dec 2017 21:46:10 -0600
> From: Paul Cantrell <cantrell at pobox.com>
> To: Nevin Brackett-Rozinsky <nevin.brackettrozinsky at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Accepted
> with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”
> Message-ID: <BC0D845E-9DDA-4FFF-84AD-DEEB3A265056 at pobox.com>
> Content-Type: text/plain; charset="utf-8"
>
> Yes. If we’re fussing over the verb tense, “compacted” is clearly correct. Where did “compacting” come from? The API guidelines state:
>
>> Prefer to name the nonmutating variant using the verb’s past participle (usually appending “ed”).
>
>
> …and (emphasis added):
>
>> When adding “ed” _is not grammatical because the verb has a direct object_, name the nonmutating variant using the verb’s present participle, by appending “ing.”
>
> Thus “joined” and “sorted” — also no-args methods where the verb has no direct object.
>
> BUT
>
> The existing methods “filter” and “reduce” seem the nearest peers to the proposed “compact,” and we do not call them “filtered” and “reduced.” Those are the methods with which the new one should maintain consistency.
>
> P
>
>
>> On Dec 19, 2017, at 5:52 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> If we’re bikeshedding the verb tense then “compactMap” sounds right to me, and adding “ing” would be needlessly verbose.
>>
>> For the non-mapping version, I’d lean toward “compacted”. However, we could also postpone the debate over its spelling until such time as we are actually ready to introduce it.
>>
>> Nevin
>>
>>
>>
>> On Tue, Dec 19, 2017 at 6:42 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>>
>>> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On Dec 19, 2017, at 8:56 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> 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).
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/e14a7117/attachment-0001.html>
>
> ------------------------------
>
> Message: 16
> Date: Tue, 19 Dec 2017 18:15:04 -1000
> From: Howard Lovatt <howard.lovatt at gmail.com>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <2D698C32-F6AE-4166-B196-793F294DC9D2 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> As an aside: there seems to be increasingly comments about proposals that say:
>
> 1. This was discussed at the evaluation stage and rejected.
> 2. This is how it is implemented in the patch.
>
> And other comments along those lines. Neither the pre-proposal discussions nor the proposed implementation are intended to limit the scope of the review. Therefore I don’t think people should raise this as reasons. You should remember that the process is deliberately staged this way and different people may well be commenting (in fact the process rather assumes that people in the formal review will be a wider set of people).
>
> Anyway gripe over.
>
> Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
> What is your evaluation of the proposal?
>
> +1/2
>
> I only give this a half because whilst it is important I can see three issues:
>
> 1. It doesn’t seem very Swift like to have a different rule, default non-exhaustive, for public as opposed to non-public.
>
> 2. It doesn’t seem very Swift like to have the default the unsafe case.
>
> 3. Other languages have better solutions - see below under other languages
>
> Is the problem being addressed significant enough to warrant a change to Swift?
>
> Yes, Swift ABI compatibility going forwards is important
>
> Does this proposal fit well with the feel and direction of Swift?
>
> No. As mentioned above different rules for public and a non-safe default don’t see that Swift like.
>
> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>
> Both Java and Scala have a better solution. In these languages enums (Scala calls them case classes) can implement protocols and the user of an enum rarely writes a switch statement, instead they call protocol methods. Enums in these languages are a fixed set of derived classes; i.e. normal OO programming rather than functional programming, which works well in the case of wanting to expand later the number of enum cases.
>
> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>
> Have followed the discussions. Used enums in Swift and other languages extensively.
>
> -- Howard.
>
>> On 19 Dec 2017, at 12:58 pm, Ted Kremenek <kremenek at apple.com> wrote:
>>
>> 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?
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/86a75ed9/attachment-0001.html>
>
> ------------------------------
>
> Message: 17
> Date: Tue, 19 Dec 2017 23:44:40 -0500
> From: Xiaodi Wu <xiaodi.wu at gmail.com>
> To: Howard Lovatt <howard.lovatt at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID:
> <CAGY80ukE839j2bqGBDqJL0E=AZ7MPHYqU-3AtT092XLgby8o3Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> As an aside: there seems to be increasingly comments about proposals that
>> say:
>>
>> 1. This was discussed at the evaluation stage and rejected.
>> 2. This is how it is implemented in the patch.
>>
>> And other comments along those lines. Neither the pre-proposal discussions
>> nor the proposed implementation are intended to limit the scope of the
>> review. Therefore I don’t think people should raise this as reasons. You
>> should remember that the process is deliberately staged this way and
>> different people may well be commenting (in fact the process rather assumes
>> that people in the formal review will be a wider set of people).
>>
>>
> No, previous discussion don't limit the scope of review per se, but it's
> not helpful to rehash the same arguments again. We want to encourage
> everyone to contribute their most thought-out comments as early in the
> process as possible to give those who propose ideas the fullest chance to
> flesh out any revisions. However, everyone has finite time to contribute,
> and if the same discussions are merely replayed at every stage of review,
> then the process actively discourages thoughtful early participation. After
> all, why bother defending ideas at the pre-proposal stage if I'm going to
> have to spend the time repeating myself in a few months' time anyway?
>
> Of course, if a wider set of people have _new_ comments, those are welcome
> at a later stage. But, there seems to be a sense that if _I_ haven't said
> something already, then _I_ should say it whether or not the same viewpoint
> has already been aired. In my view, such an approach should be actively
> discouraged for the reasons above. Although a strong consensus within the
> community should certainly be accounted for, this list--even at the formal
> review stage--doesn't even come close to approximating the community of
> Swift users at large. Thus, review is not a vote-counting exercise to
> maximize the number of people who chime in, but rather it is meant to
> maximize the number of ideas and perspectives that are aired. If it's
> already been said, it doesn't need to be said again, even if _I_ haven't
> said it myself.
>
>
>> Anyway gripe over.
>>
>> Proposal link: https://github.com/apple/swift-evolution/blob/
>> master/proposals/0192-non-exhaustive-enums.md
>>
>>
>> -
>>
>> What is your evaluation of the proposal?
>>
>> +1/2
>>
>> I only give this a half because whilst it is important I can see three
>> issues:
>>
>> 1. It doesn’t seem very Swift like to have a different rule, default
>> non-exhaustive, for public as opposed to non-public.
>>
>> 2. It doesn’t seem very Swift like to have the default the unsafe
>> case.
>>
>> 3. Other languages have better solutions - see below under other
>> languages
>> -
>>
>> Is the problem being addressed significant enough to warrant a change
>> to Swift?
>>
>> Yes, Swift ABI compatibility going forwards is important
>> -
>>
>> Does this proposal fit well with the feel and direction of Swift?
>>
>> No. As mentioned above different rules for public and a non-safe
>> default don’t see that Swift like.
>> -
>>
>> If you have used other languages or libraries with a similar feature,
>> how do you feel that this proposal compares to those?
>>
>> Both Java and Scala have a better solution. In these languages enums
>> (Scala calls them case classes) can implement protocols and the user of an
>> enum rarely writes a switch statement, instead they call protocol methods.
>> Enums in these languages are a fixed set of derived classes; i.e. normal OO
>> programming rather than functional programming, which works well in the
>> case of wanting to expand later the number of enum cases.
>> -
>>
>> How much effort did you put into your review? A glance, a quick
>> reading, or an in-depth study?
>> Have followed the discussions. Used enums in Swift and other languages
>> extensively.
>>
>>
>> -- Howard.
>>
>> On 19 Dec 2017, at 12:58 pm, Ted Kremenek <kremenek at apple.com> wrote:
>>
>> 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?
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/80c26495/attachment-0001.html>
>
> ------------------------------
>
> Message: 18
> Date: Tue, 19 Dec 2017 19:42:04 -1000
> From: Howard Lovatt <howard.lovatt at gmail.com>
> To: Xiaodi Wu <xiaodi.wu at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <85AC8613-7F54-49A1-A6E3-1C325F65FAEA at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Let me give an example. The recent discussion about filterMap aired in the discussion stage misgivings about the name; but it went to review with the name filterMap. At the review stage more misgivings were raised, the review was returned for amendment. An amended name of compactMap was put forward and this was accepted yesterday as a result of the 2nd review. I think that this shows how the process can work well. If the discussions were shut down with “already covered on Swift Evolution”, then the result wouldn’t be as good.
>
> If an argument has been put forward on Evolution, is in the alternatives section, and people are still raising the point; it is probably safe to assume that the argument hasn’t carried the day and should be revisited.
>
> -- Howard.
>
>>> On 19 Dec 2017, at 6:44 pm, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>>
>>> On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
>>> As an aside: there seems to be increasingly comments about proposals that say:
>>>
>>> 1. This was discussed at the evaluation stage and rejected.
>>> 2. This is how it is implemented in the patch.
>>>
>>> And other comments along those lines. Neither the pre-proposal discussions nor the proposed implementation are intended to limit the scope of the review. Therefore I don’t think people should raise this as reasons. You should remember that the process is deliberately staged this way and different people may well be commenting (in fact the process rather assumes that people in the formal review will be a wider set of people).
>>
>> No, previous discussion don't limit the scope of review per se, but it's not helpful to rehash the same arguments again. We want to encourage everyone to contribute their most thought-out comments as early in the process as possible to give those who propose ideas the fullest chance to flesh out any revisions. However, everyone has finite time to contribute, and if the same discussions are merely replayed at every stage of review, then the process actively discourages thoughtful early participation. After all, why bother defending ideas at the pre-proposal stage if I'm going to have to spend the time repeating myself in a few months' time anyway?
>>
>> Of course, if a wider set of people have _new_ comments, those are welcome at a later stage. But, there seems to be a sense that if _I_ haven't said something already, then _I_ should say it whether or not the same viewpoint has already been aired. In my view, such an approach should be actively discouraged for the reasons above. Although a strong consensus within the community should certainly be accounted for, this list--even at the formal review stage--doesn't even come close to approximating the community of Swift users at large. Thus, review is not a vote-counting exercise to maximize the number of people who chime in, but rather it is meant to maximize the number of ideas and perspectives that are aired. If it's already been said, it doesn't need to be said again, even if _I_ haven't said it myself.
>>
>>>
>>> Anyway gripe over.
>>>
>>> Proposal link: https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md
>>> What is your evaluation of the proposal?
>>>
>>> +1/2
>>>
>>> I only give this a half because whilst it is important I can see three issues:
>>>
>>> 1. It doesn’t seem very Swift like to have a different rule, default non-exhaustive, for public as opposed to non-public.
>>>
>>> 2. It doesn’t seem very Swift like to have the default the unsafe case.
>>>
>>> 3. Other languages have better solutions - see below under other languages
>>>
>>> Is the problem being addressed significant enough to warrant a change to Swift?
>>>
>>> Yes, Swift ABI compatibility going forwards is important
>>>
>>> Does this proposal fit well with the feel and direction of Swift?
>>>
>>> No. As mentioned above different rules for public and a non-safe default don’t see that Swift like.
>>>
>>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>>
>>> Both Java and Scala have a better solution. In these languages enums (Scala calls them case classes) can implement protocols and the user of an enum rarely writes a switch statement, instead they call protocol methods. Enums in these languages are a fixed set of derived classes; i.e. normal OO programming rather than functional programming, which works well in the case of wanting to expand later the number of enum cases.
>>>
>>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>>
>>> Have followed the discussions. Used enums in Swift and other languages extensively.
>>>
>>> -- Howard.
>>>
>>>> On 19 Dec 2017, at 12:58 pm, Ted Kremenek <kremenek at apple.com> wrote:
>>>>
>>>> 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?
>>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/3a42fa54/attachment-0001.html>
>
> ------------------------------
>
> Message: 19
> Date: Wed, 20 Dec 2017 01:34:13 -0500
> From: Xiaodi Wu <xiaodi.wu at gmail.com>
> To: Howard Lovatt <howard.lovatt at gmail.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID:
> <CAGY80ukcra7iOQ4GZrs5o490nh8Z_UFG26DgkrbGD1NNq+B53g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Dec 20, 2017 at 12:42 AM, Howard Lovatt <howard.lovatt at gmail.com>
> wrote:
>
>> Let me give an example. The recent discussion about filterMap aired in the
>> discussion stage misgivings about the name; but it went to review with the
>> name filterMap. At the review stage more misgivings were raised, the review
>> was returned for amendment. An amended name of compactMap was put forward
>> and this was accepted yesterday as a result of the 2nd review. I think that
>> this shows how the process can work well. If the discussions were shut down
>> with “already covered on Swift Evolution”, then the result wouldn’t be as
>> good.
>>
>> If an argument has been put forward on Evolution, is in the alternatives
>> section, and people are still raising the point; it is probably safe to
>> assume that the argument hasn’t carried the day and should be revisited.
>>
>
> The name of `filterMap` was reviewed a second time because, if I recall,
> the core team felt that there might be _additional_ ideas not yet surveyed
> the first time. By contrast, if an argument has already been discussed and
> is even incorporated into the text of the proposal, then I very strongly
> disagree that raising the point again is to be encouraged. It's a different
> matter if you have additional _evidence_ or alternative _reasoning_ to
> support an argument.
>
>> On 19 Dec 2017, at 6:44 pm, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> On Tue, Dec 19, 2017 at 11:15 PM, Howard Lovatt via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> As an aside: there seems to be increasingly comments about proposals that
>>> say:
>>>
>>> 1. This was discussed at the evaluation stage and rejected.
>>> 2. This is how it is implemented in the patch.
>>>
>>> And other comments along those lines. Neither the pre-proposal
>>> discussions nor the proposed implementation are intended to limit the scope
>>> of the review. Therefore I don’t think people should raise this as reasons.
>>> You should remember that the process is deliberately staged this way and
>>> different people may well be commenting (in fact the process rather assumes
>>> that people in the formal review will be a wider set of people).
>>>
>>>
>> No, previous discussion don't limit the scope of review per se, but it's
>> not helpful to rehash the same arguments again. We want to encourage
>> everyone to contribute their most thought-out comments as early in the
>> process as possible to give those who propose ideas the fullest chance to
>> flesh out any revisions. However, everyone has finite time to contribute,
>> and if the same discussions are merely replayed at every stage of review,
>> then the process actively discourages thoughtful early participation. After
>> all, why bother defending ideas at the pre-proposal stage if I'm going to
>> have to spend the time repeating myself in a few months' time anyway?
>>
>> Of course, if a wider set of people have _new_ comments, those are welcome
>> at a later stage. But, there seems to be a sense that if _I_ haven't said
>> something already, then _I_ should say it whether or not the same viewpoint
>> has already been aired. In my view, such an approach should be actively
>> discouraged for the reasons above. Although a strong consensus within the
>> community should certainly be accounted for, this list--even at the formal
>> review stage--doesn't even come close to approximating the community of
>> Swift users at large. Thus, review is not a vote-counting exercise to
>> maximize the number of people who chime in, but rather it is meant to
>> maximize the number of ideas and perspectives that are aired. If it's
>> already been said, it doesn't need to be said again, even if _I_ haven't
>> said it myself.
>>
>>
>>> Anyway gripe over.
>>>
>>> Proposal link: https://github.com/apple/swift-evolution/blob/master/
>>> proposals/0192-non-exhaustive-enums.md
>>>
>>>
>>> -
>>>
>>> What is your evaluation of the proposal?
>>>
>>> +1/2
>>>
>>> I only give this a half because whilst it is important I can see
>>> three issues:
>>>
>>> 1. It doesn’t seem very Swift like to have a different rule,
>>> default non-exhaustive, for public as opposed to non-public.
>>>
>>> 2. It doesn’t seem very Swift like to have the default the unsafe
>>> case.
>>>
>>> 3. Other languages have better solutions - see below under other
>>> languages
>>> -
>>>
>>> Is the problem being addressed significant enough to warrant a change
>>> to Swift?
>>>
>>> Yes, Swift ABI compatibility going forwards is important
>>> -
>>>
>>> Does this proposal fit well with the feel and direction of Swift?
>>>
>>> No. As mentioned above different rules for public and a non-safe
>>> default don’t see that Swift like.
>>> -
>>>
>>> If you have used other languages or libraries with a similar feature,
>>> how do you feel that this proposal compares to those?
>>>
>>> Both Java and Scala have a better solution. In these languages enums
>>> (Scala calls them case classes) can implement protocols and the user of an
>>> enum rarely writes a switch statement, instead they call protocol methods.
>>> Enums in these languages are a fixed set of derived classes; i.e. normal OO
>>> programming rather than functional programming, which works well in the
>>> case of wanting to expand later the number of enum cases.
>>> -
>>>
>>> How much effort did you put into your review? A glance, a quick
>>> reading, or an in-depth study?
>>> Have followed the discussions. Used enums in Swift and other
>>> languages extensively.
>>>
>>>
>>> -- Howard.
>>>
>>> On 19 Dec 2017, at 12:58 pm, Ted Kremenek <kremenek at apple.com> wrote:
>>>
>>> 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?
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/ad7544c4/attachment-0001.html>
>
> ------------------------------
>
> Message: 20
> Date: Tue, 19 Dec 2017 23:26:11 -0800
> From: Douglas Gregor <dgregor at apple.com>
> To: Chris Lattner <clattner at nondot.org>
> Cc: Swift Evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] Proposal: Introduce User-defined
> "Dynamic Member Lookup" Types
> Message-ID: <72D00A92-1DD2-4989-A898-72C9B66398B5 at apple.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>> On Dec 1, 2017, at 9:37 AM, Chris Lattner <clattner at nondot.org> wrote:
>>
>> On Dec 1, 2017, at 12:26 AM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>>>> On Nov 30, 2017, at 10:05 PM, Chris Lattner <clattner at nondot.org <mailto:clattner at nondot.org>> wrote:
>>>> Hi Doug,
>>>>
>>>> Thank you for the detailed email. I have been traveling today, so I haven’t had a chance to respond until now. I haven’t read the down-thread emails, so I apologize if any of this was already discussed:
>>>>
>>>>> I think better interoperability with Python (and other OO languages in widespread use) is a good goal, and I agree that the implementation of the feature described is straight-forward and not terribly invasive in the compiler.
>>>>
>>>> Fantastic, I’m really pleased to hear that! I only care about solving the problem, so if we can find a good technical solution to the problems than I’ll be happy.
>>
>> After thinking about your email a bit more, I think I might understand the disconnect we’re having. I think we have different versions in mind of what “success” looks like:
>>
>> I believe your view is that people start using Python APIs from their Swift code, but gradually add type annotations (either inline or in a sidecar database) to make those APIs progressively more Swifty. New features will be added to Python (its type system, compilers, databases for common APIs, etc) to improve this interoperability, along the lines of what we’ve done for Objective-C over the years. Fast forward several years, and large Python libraries would be nice to use from Swift - perhaps nicer than they are to use from Python itself. This view aligns with what happened with Objective-C <-> Swift interoperability.
>>
>> In contrast, I’m specifically interested in developers in certain large domains (e.g. data science and ML) which are “forced” to use Python because that is where all the libraries are. I have spoken to many of these sorts of people, and a large number of them really *dislike* using Python for all the obvious reasons (including the tooling issues you point out). My view of success is that we allow them to write all of *their code* in Swift, which will lead to a massive quality of life benefit for these frustrated people. You’re right that they will still chaff when using imported Python APIs (which don’t feel “swifty” for LOTS of reasons - e.g. method naming and design patterns), but my view is that this will provide incentive for these people to provide a proper Swift implementation for these libraries over time.
>>
>> In short, your end game is a pervasively intertwined Swift/Python world (like ObjC and Swift are). My view is that Swift holds Python at arm's length, and wins over the hearts and minds of developers, leading to new Swift APIs designed for Swift.
>
> That’s not the end game I’m looking at. I’d rather make it feasible to generate Swift wrappers for Python libraries that fit well into Swift’s existing machinery. The complexity goes outside the compiler, with small extralinguistic tie-ins to make it work well.
>
>> I’m not sure if you agree with that portrayal of your position, and if not, I’m sorry and will try to understand another way. However, if I’m close, then I have several concerns about that vision and don’t believe the end-game is achievable or better than what I’m proposing. Consider:
>>
>> - I don’t think there will be a lot of success getting people who *actually love* Python to use Swift, unless there is already an extrinsic reason for them to use it.
>> - Type hints are not widely used in Python, and there are believable reasons that they won’t ever be. Because they are specifically poorly suited for libraries, their use seems to be in “user’s own code” - but my proposal solves this already! See below for examples.
>> - Even if type hints were widely adopted, it would require massive extensions to them and to Python to make them be "good enough” to provide value for the things you’re envisioning. Analogs to instancetype, objc generics, lots of the C macros, and many of the other things we’ve added to ObjC would have to be added.
>> - The Python community has no reason to do this work for the Swift community, or accept changes to Python that are required to make this actually great.
>> - Beyond the core type system, the Python and Objective-C languages work extremely differently in other ways (e.g. lack of umbrella headers making AnyObject-style dispatch questionable).
>> - Even with those annotations and all the work, the APIs we’d end up with are not going to be good Swift APIs. I don’t think that “renamification” and "IUO audits" would ever actually happen in practice, for example.
>> - I believe the engineering effort required to implement this vision is so massive (including the changes to Swift, Python, and Python libraries) that it simply will never actually happen.
>
> They don’t have to be good, strictly-typed APIs to be useful. They should have method/property names, have documentation, and be associated with named classes to work well with existing tooling.
>
>> More concerning to me is that your design of using the existing AnyObject type presents a really concerning technical problem, scalability: It is not simply a Swift/ObjC/Python world, Javascript is also super important. There are also a number of other less-widely used dynamic languages that are interesting. Your design leads to them all being mashed together into a common runtime system. I cannot imagine how this would end up being a good thing for system complexity, and would lead to each of them being jeopardized in different ways. As I have mentioned before numerous times, it also opens the door for enormous Swift compiler complexity, as each of the object models need to be supported in the compiler (so you can subclass each languages’ types), and many other complexities.
>
> The AnyObject model of dispatching to any method within a given dynamic space (whether it’s Objective-C or Python or something else) fits well into Swift. You’re absolutely right that we can’t make Python objects work with AnyObject.
>
>> If you are serious about improving the tooling situation for people using Python APIs in Swift, the most natural way to do so is to follow the approach that the MyPy community (they are the ones who have thought about this the most) is using: provide progressive typing extensions, use data flow analysis to propagate around types, and enhance the tooling to have support this. I’m skeptical that this will ever be worthwhile, but a sketch could look like this:
>
> I doubt this would be worthwhile. If we wanted to do something along these lines, we’d want to seriously investigate something akin to gradual typing.
>>
>> Similarly, there is no reason to do anything to make the second and third examples work nicely in Swift: you’d just define a Swift class, and a Swift function.
>>
>> MyPy:
>>
>> class BankAccount:
>> def __init__(self, initial_balance: int = 0) -> None:
>> self.balance = initial_balance
>> def deposit(self, amount: int) -> None:
>> self.balance += amount
>> def withdraw(self, amount: int) -> None:
>> self.balance -= amount
>> def overdrawn(self) -> bool:
>> return self.balance < 0
>>
>> my_account = BankAccount(15)
>> my_account.withdraw(5)
>> print(my_account.balance)
>> Swift:
>>
>> class BankAccount {
>> var balance : Int
>> init(initialBalance: Int) { … }
>> func deposit(….
>> }
>>
>> Even the proposals that I’m making - simple and isolated though they are - are enough to provide a major quality of life improvement for people writing large amounts of code against Python APIs.
>
> They’re an improvement to the resulting code (i.e., the Swift code looks comparable to the Python code), but it’s not a quality-of-life improvement for the process of writing the code (or understanding it once it’s written), because you don’t get any of the tooling benefits you’re used to having as a Swift programmer: no code completion, no “”quick help”, no go-to-definition.
>
>> Beyond that, they are small extensions with low complexity, scale to supporting many different dynamic languages over time, require a level of engineering effort that is plausible to be built, and do not require some sort of "executive buy in” from the Python community.
>
> Here’s an alternative proposal that provides a better development experience: write a wrapper generator, in Python, that maps a Python module’s interfaces to Swift, and provide small tie-ins to the compiler to make it fit well. Take the example from the DynamicMemberLookup proposal:
>
> class Dog:
> """Man's best friend"""
> def __init__(self, name):
> """Summon a new dog"""
> self.name = name
> self.tricks = [] # creates a new empty list for each dog
>
> def add_trick(self, trick):
> """Teach the old dog a new trick"""
> self.tricks.append(trick)
>
>
> The output of the wrapper generator is:
>
> /// Man's best friend
> @_foreign(python)
> class Dog : PythonObject {
> /// Summon a new dog
> @_foreign(python, “__init__”)
> init(_ name: PythonArgument) { /* code to dynamically call __init__ on the Dog class object*/ }
>
> /// Teach the old dog a new trick
> @_foreign(python, “add_trick”)
> func add_trick(_ trick: PythonArgument) -> PythonObject? { /* code to dynamically call add_trick */ }
> }
>
> Several pieces above require explanation, but first the code to use this from Swift:
>
> import DogModule
> let dog = Dog("Brianna")
> dog.add_trick("Roll over")
> log do2 = Dog("Kaylee").add_trick("snore")
>
> Now, because we have declarations in the Swift module, the tools helped us write this code: I got code completion for the “Dog” type, its initializers, its “add_trick” method. The Python docstrings were carried through into documentation comments that show up in my IDE. I can inspect the Swift interface created by the wrapper generator to see what it looks like; my class browser can show me the Python class hierarchy.
>
> Let’s break down the pieces we need to get here:
>
> PythonObject: this would be a root class, defined by the Python interoperability library:
>
> @_foreign(python)
> class PythonObject {
> static func retain(_ object: UnsafePointer<Void>) { Py_INCREF(object) }
> static func release(_ object: UnsafePointer<Void>) {Py_DECREF(object) }
> }
>
> PythonObject is a foreign class for the Python language (hence the @_foreign). So while you get subtyping as normal (Dog is a subtype of PythonObject), they aren’t a subtype of AnyObject because it’s not a native object model. Nor could you mix a foreign class marked as @_foreign(python) with one marked as @_foreign(ruby), but they’re different object models.
>
> The retain/release operations would be called by the compiler in the obvious places. It shouldn’t be too difficult to build an appropriate value witness table to make this work.
>
> PythonArgument: This is a protocol to which any type can conform to map it into Python, and IIRC you already have this in your design in some form:
>
> protocol PythonArgument {
> func toPythonObject() -> PythonObject
> }
>
> extension PythonObject: PythonArgument {
> func toPythonObject() -> PythonObject { return self }
> }
>
> extension Int: PythonArgument {
> func toPythonObject() -> PythonObject { … }
> }
>
> @_foreign on methods/properties/etc.: This is there to enable AnyObject-style dispatch. Consider the add_trick example:
>
> @_foreign(python, “add_trick”)
> func add_trick(_ trick: PythonArgument) -> PythonObject { /* code to dynamically call add_trick */ }
>
> The two arguments to @_foreign are the foreign-class-model indicator (python): one gets AnyObject lookup from objects whose type is in that same foreign class space (e.g., PythonObject is also in the “python” foreign class model), and the second string (here, “add_trick”) is the uniquing string that indicates what name would be passed through to the underling runtime. This becomes important when you have overlap at different parts in the class hierarchy, e.g.,
>
> @_foreign(python)
> class MagicShow: PythonObject {
> @_foreign(python, “add_trick”)
> func add_trick(_ trick: PythonArgument) -> PythonObject? { … }
> }
>
> And then we have something like:
>
> func foo(po: PythonObject) {
> po.add_trick?(“something”) // finds both Dog.add_trick(_:) and MagicShow.add_trick(_:), but since they’re both uniqued by “add_trick” and have the same signature, we can pick one arbitrarily
> }
>
> This is a generalization of how AnyObject dispatch already works in the type checker. For Objective-C, AnyObject is the root for the “objc” class model and the Objective-C selector (with + or - prepended) is used as the uniquing key; you can see the code at https://github.com/apple/swift/blob/master/lib/Sema/ConstraintSystem.cpp#L265-L273.
>
> Factory initializers: unfortunately, to actually make initializers work cleanly, we’ll need something like factory initializers in the language. We should have those anyway, but until we get them one can fake it with top-level functions:
>
> @_foreign(python, “__init__”)
> func Dog(_ name: PythonArgument) -> Dog { /* … */ }
>
> “Truly” dynamic calls: Python code does dynamically create new properties, methods, classes, etc. Those won’t get reflected into the generated Swift interface (because the wrapper generator won’t see them when it just imports the module to inspect it). So, there needs to be some string-based interface for such dynamic calls, which would be provided by the interoperability library in whatever syntax makes it clear what’s happening:
>
> extension PythonObject {
> subscript(property name: String) -> PythonObject? { get { /* … */ } set { /* … */ }
> func call(_ methodName: String, _ args: PythonArgument…, keywordArgs: [String: PythonArgument] = [:]) -> PythonObject? { … }
> }
>
> This enables the fully-dynamic behavior, but makes it clear when we’ve conjured up the name as a string.
>
> On-demand wrapper generation: you’ve mentioned earlier in this thread that it’s important to support the playgrounds use case, where one can import whatever Python modules are available to play with them. I *personally* don’t think running a one-off wrapper script once per module is all that onerous, but if it is, we could extend the Swift compiler with a very light plugin mechanism where the plugin mechanism has two operations:
>
> 1) Enumerate the names of modules that it can translate (e.g., find all of the Python modules in the Python path and current working directory), and
> 2) Given a module name, produce the Swift wrapper code for the Swift compiler to then compile (and cache)
>
> Overall, it’s probably more work than DynamicMemberLookup, but it provides a more friendly development experience because the entities in the Python module show throw in Swift—they’re documented, inspectable, code-completable, etc. We get the class hierarchy reflected into Swift so we get proper subtyping behavior. And writing these wrapper generators is something that is easily hackable by anyone who knows the languages involved, it’s easy to test and improve over time.
>
> - Doug
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/48514157/attachment-0001.html>
>
> ------------------------------
>
> Message: 21
> Date: Wed, 20 Dec 2017 10:00:30 +0100
> From: Sebastian Hagedorn <sebastian at iosphere.de>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <B3A863D9-7617-417E-9483-516D608B173A at iosphere.de>
> Content-Type: text/plain; charset="utf-8"
>
>> What is your evaluation of the proposal?
>>
> +1 if a `future` case (or similar solution… “unknown” might be a nice keyword, although some enums probably have an `.unknown` case which could be confusing) is added.
>> Is the problem being addressed significant enough to warrant a change to Swift?
>>
> I guess so – I understand this is a real issue for binary libraries (so basically, Apple).
>
> I don’t think it’s an issue for open source libraries. Forcing the clients to update their code when they update the library (which they can do when they choose to, usually) seems reasonable to me, compared to the risk of not handling the new cases.
>> Does this proposal fit well with the feel and direction of Swift?
>>
> I don’t mind the default and I believe it’s ok to leave it to the library author to decide whether or not an enum should be exhaustive.
>
> That said, I don’t think “you need to add a default case” feels very Swifty. It forces you to write code that you essentially have no idea about, so I would assume I’d just always put in an assert so I notice it in debug/beta builds, and keep my fingers crossed ignoring the unknown case doesn’t do any harm in release builds.
>
> I strongly disagree with this:
>
>> The expectation is that switches over non-exhaustive enums are uncommon.
>
>
> Basically every time I interact with an enum, I switch over it, to make sure I don’t forget anything, and to make sure I reconsider my code if the library changes. Since most SDK enums will become non-exhaustive, this is the 99% case for me.
>
> Re: the future case: I don’t expect to actually put any code in there. If it’s code I intend to run in any case, it will typically be outside of the switch statement. Since the semantic of the new case is unknown to me, what code should I write to handle it? For that reason, I don’t think testability is a real issue here. I believe the limitation for single-value matching is fine for now, and could probably be extended to something like `case (true, future)`.
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>
> No.
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>
> Carefully read the proposal and followed some of the previous discussions.
>
>
>> On 19. Dec 2017, at 23:58, Ted Kremenek <kremenek at apple.com> 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 <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 <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 <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-announce at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/b5bc985c/attachment-0001.html>
>
> ------------------------------
>
> Message: 22
> Date: Wed, 20 Dec 2017 10:44:47 +0100
> From: Jérôme Duquennoy <jerome+swift at duquennoy.fr>
> To: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <2A072F98-0D54-488C-B351-91EF76A13A52 at duquennoy.fr>
> Content-Type: text/plain; charset=us-ascii
>
> Hi guys,
>
> I am part of the people mentioned in "Preserve exhaustiveness diagnostics for non-exhaustive enums" : I see the completeness check as a major feature of enums, that makes a difference between it and a list of constants in multiple cases.
> So much that in the coding rules of the company I work for, the use of default case requires some specific justification at review time.
>
> I have a positive opinion on this evolution if it comes with a solution to preserve exhaustiveness diagnostics. Otherwise, I think it lowers the ease of maintenance of code using external libraries.
>
> One of the risk I fear is that libraries builders might just forget to add the @exhaustive keyword. So it might end up being a pretty common case to have to specify "I want this switch to be exhaustive", just to not loose on maintainability. This could lead to a situation similar to the "fileprivate", that ended up being used much more than expected.
>
> It is not exactly in the scope of that review, but in the two solution for enforcing exhaustiveness drafted in that proposal, I would rather avoid the second one (the switch!). It would contradict the fact that as of today, the use of the exclamation mark in swift is a pretty clear sign that you are disabling some compiler-provided security at your own risk, and that it might lead to runtime crash (force unwrap, force cast, ...).
> Here, requesting a switch to be exhaustive is adding one more compiler check. It cannot lead to a runtime crash.
> I will be happy to discuss it further in a future review.
>
> Jerome
>
> ------------------------------
>
> Message: 23
> Date: Wed, 20 Dec 2017 02:39:57 -0800
> From: Brent Royal-Gordon <brent at architechies.com>
> To: Sebastian Hagedorn <sebastian at iosphere.de>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <91A6D133-53D8-45E7-AB06-BF9E0875495D at architechies.com>
> Content-Type: text/plain; charset="utf-8"
>
>>> On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> The expectation is that switches over non-exhaustive enums are uncommon.
>>
>>
>> Basically every time I interact with an enum, I switch over it, to make sure I don’t forget anything, and to make sure I reconsider my code if the library changes. Since most SDK enums will become non-exhaustive, this is the 99% case for me.
>
> Is that typical of your interactions with, say, `UIViewAnimationTransition`?
>
> There are three categories of enums in the SDK:
>
> 1) Those which you switch over and which are inherently exhaustive. For example, `ComparisonResult` will never, ever have a case besides `orderedAscending`, `orderedSame`, and `orderedDescending`. All possible values fit into one of these three categories (other than those for which comparison is not a valid operation). You want an exhaustive switch for these.
>
> 2) Those which you switch over but which could have cases added in the future. For example, `SKPaymentTransactionState` (representing the state of an in-app purchase) may sometimes need additional cases; one was already added in iOS 8 for a parental permission feature. You want a nonexhaustive switch for these, with a `default` clause containing some fallback behavior (like skipping the associated entry or showing an error message).
>
> 3) Those which you almost never switch over at all; they are simply used as opaque inputs to APIs in the same framework. For example, very few pieces of code ever need to examine or use a `UIViewAnimationTransition`; they just need to pass one into the proper UIKit animation APIs. (Error types are another example—you should catch specific errors you know you want to handle specially, but you should never imagine that you have thought of all possible errors.) You basically don't care about the switch behavior of these enums; the compiler could even ban switching over them and you would probably never notice.
>
> Category 1 enums should be exhaustive; category 2 and 3 should be nonexhaustive. So the question is, do category 1 enums outnumber category 2 and 3? You seem to suggest that they do, but I very much doubt that. My suspicion is that category 3 is the most common, followed by category 2, with category 1 bringing up the rear. The authors of the proposal say they surveyed Foundation enums to test this theory:
>
>> To see how this distinction will play out in practice, I investigated the public headers of Foundation in the macOS SDK. Out of all 60 or so NS_ENUMs in Foundation, only 6 of them are clearly exhaustive:
>>
>> • ComparisonResult
>> • NSKeyValueChange / NSKeyValueSetMutationKind
>> • NSRectEdge
>> • FileManager.URLRelationship
>> • maybe Decimal.CalculationError
>>
>> ...with a handful more that could go either way, such as Stream.Status. This demonstrates that there is a clear default for public enums, at least in Objective-C.
>
> Maybe a survey of another library like Alamofire would show different results; if you think it would, by all means feel free to demonstrate it.
>
> Having said that, I too think that `future` or `unknown` is a good idea, and I think we should strongly consider adding it. Doing so would restore many of the correctness benefits of exhaustiveness checking to nonexhaustive enums, significantly reducing the painful parts of this feature.
>
> --
> Brent Royal-Gordon
> Architechies
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/37f49540/attachment-0001.html>
>
> ------------------------------
>
> Message: 24
> Date: Wed, 20 Dec 2017 14:33:54 +0200
> From: Letanyan Arumugam <letanyan.a at gmail.com>
> To: Swift Evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
> Message-ID: <9CD78AB6-6130-4BA3-8AC8-3E8AFAD8A6AA at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>>
>> What is your evaluation of the proposal?
>>
>>
> +1 it solves an important problem in our ecosystem.
>
>> 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?
>>
>>
> This is weird because I feel that having @exhaustive as the default would be more inline with the feel of Swift, but the current default is better for usability.
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>
>>
> Have not used a similar feature.
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>
>>
>
> Read the proposal and a little bit of research into the links from the proposal.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/1665501c/attachment-0001.html>
>
> ------------------------------
>
> Message: 25
> Date: Wed, 20 Dec 2017 13:43:20 +0100
> From: Sebastian Hagedorn <sebastian at iosphere.de>
> To: Brent Royal-Gordon <brent at architechies.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] [swift-evolution-announce] [Review] SE
> 0192 - Non-Exhaustive Enums
> Message-ID: <E1964AB8-8CFF-4E2F-8E8A-3B1555E48591 at iosphere.de>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for your thoughts.
>
> I think 3) is indeed a very common case, but also not affected by this proposal or the general issue at all. Unless I’m missing something, I think it makes sense to limit the discussion to those enums that are typically switched over in client code.
>
> I don’t think 1) outnumbers 2), which is exactly why I think it is important to have some sort of exhaustive-checking for 2). If 2) was an edge cases, I wouldn’t mind, because 1) behaves the same way with or without the implementation of this proposal.
>
> What I was trying to say is: 99% of the times I switch over an enum, I do want to consider all available cases in my code, which also means I want to be informed (by a warning) if I’m missing something. Without anything like `future`, I’ll end up with switches that used to be exhaustive, but are not anymore when the library author adds a case, and I don’t learn about it until I hit such a case at runtime (documentation aside), which may rarely happen. I’m aware that there may be a period of time during which I haven’t updated my code and my code has to deal with unexpected cases, but as soon as I get to compile my code with the current SDK, I’d like to learn about new cases.
>
>
>>> On 20. Dec 2017, at 11:39, Brent Royal-Gordon <brent at architechies.com> wrote:
>>>
>>>> On Dec 20, 2017, at 1:00 AM, Sebastian Hagedorn via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>
>>>> The expectation is that switches over non-exhaustive enums are uncommon.
>>>
>>>
>>> Basically every time I interact with an enum, I switch over it, to make sure I don’t forget anything, and to make sure I reconsider my code if the library changes. Since most SDK enums will become non-exhaustive, this is the 99% case for me.
>>
>> Is that typical of your interactions with, say, `UIViewAnimationTransition`?
>>
>> There are three categories of enums in the SDK:
>>
>> 1) Those which you switch over and which are inherently exhaustive. For example, `ComparisonResult` will never, ever have a case besides `orderedAscending`, `orderedSame`, and `orderedDescending`. All possible values fit into one of these three categories (other than those for which comparison is not a valid operation). You want an exhaustive switch for these.
>>
>> 2) Those which you switch over but which could have cases added in the future. For example, `SKPaymentTransactionState` (representing the state of an in-app purchase) may sometimes need additional cases; one was already added in iOS 8 for a parental permission feature. You want a nonexhaustive switch for these, with a `default` clause containing some fallback behavior (like skipping the associated entry or showing an error message).
>>
>> 3) Those which you almost never switch over at all; they are simply used as opaque inputs to APIs in the same framework. For example, very few pieces of code ever need to examine or use a `UIViewAnimationTransition`; they just need to pass one into the proper UIKit animation APIs. (Error types are another example—you should catch specific errors you know you want to handle specially, but you should never imagine that you have thought of all possible errors.) You basically don't care about the switch behavior of these enums; the compiler could even ban switching over them and you would probably never notice.
>>
>> Category 1 enums should be exhaustive; category 2 and 3 should be nonexhaustive. So the question is, do category 1 enums outnumber category 2 and 3? You seem to suggest that they do, but I very much doubt that. My suspicion is that category 3 is the most common, followed by category 2, with category 1 bringing up the rear. The authors of the proposal say they surveyed Foundation enums to test this theory:
>>
>>> To see how this distinction will play out in practice, I investigated the public headers of Foundation in the macOS SDK. Out of all 60 or so NS_ENUMs in Foundation, only 6 of them are clearly exhaustive:
>>>
>>> • ComparisonResult
>>> • NSKeyValueChange / NSKeyValueSetMutationKind
>>> • NSRectEdge
>>> • FileManager.URLRelationship
>>> • maybe Decimal.CalculationError
>>>
>>> ...with a handful more that could go either way, such as Stream.Status. This demonstrates that there is a clear default for public enums, at least in Objective-C.
>>
>> Maybe a survey of another library like Alamofire would show different results; if you think it would, by all means feel free to demonstrate it.
>>
>> Having said that, I too think that `future` or `unknown` is a good idea, and I think we should strongly consider adding it. Doing so would restore many of the correctness benefits of exhaustiveness checking to nonexhaustive enums, significantly reducing the painful parts of this feature.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/d2bf57b6/attachment-0001.html>
>
> ------------------------------
>
> Message: 26
> Date: Wed, 20 Dec 2017 14:36:25 +0100
> From: Karl Wagner <razielim at gmail.com>
> To: Ted Kremenek <kremenek at apple.com>
> Cc: Swift Evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
> Message-ID: <A5700150-4072-4078-B70D-8D74B9AB83A5 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
>> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution <swift-evolution at 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 <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 <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 <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, 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? 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).
>
> 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.
>> Is the problem being addressed significant enough to warrant a change to Swift?
>>
>>
> Definitely. Major part of ABI stability.
>
>> Does this proposal fit well with the feel and direction of Swift?
>>
>>
> It does indeed.
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>
>>
> I can’t remember making much use of exhaustive enums before Swift.
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>
>>
> Followed earlier discussions, read the proposal and comments so far. Even gave it a bit of thought, which was refreshing.
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/5d88db2c/attachment-0001.html>
>
> ------------------------------
>
> Message: 27
> Date: Wed, 20 Dec 2017 15:46:20 +0100
> From: Jens Persson <jens at bitcycle.com>
> To: Dave Abrahams <dabrahams at apple.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Proposal] Random Unification
> Message-ID:
> <CANmwP4in8cKd38+syma0XBQA=shj6y3-b_Gjt4mWbWrPJT5D1w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> I'd like to add a pointer to the information here:
> http://xoroshiro.di.unimi.it
>
> since AFAICS, the xoroshiro128+ generator and the method of "Generating
> uniform doubles in the unit interval" should probably be implemented in any
> modern general purpose Random API.
>
> Please correct me if there are more up to date (higher quality and faster)
> general purpose generators and ways of converting UInt64 bit patterns to
> floating point [0, 1).
>
> /Jens
>
>
>
> On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I don’t have much to say about this other than that I think the discussion
>> seems way too narrow, focusing on spelling rather than on functionality and
>> composability. I consider the “generic random number library” design to be
>> a mostly-solved problem, in the C++ standard library (
>> http://en.cppreference.com/w/cpp/numeric/random). Whatever goes into the
>> Swift standard library does not need to have all those features right away,
>> but should support being extended into something having the same general
>> shape. IMO the right design strategy is to *implement and use* a Swift
>> version of C++’s facilities and only then consider proposing [perhaps a
>> subset of] that design for standardization in Swift.
>>
>> Sent from my iPad
>>
>> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>
>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Instead, we ought to make clear to users both the features and the
>> limitations of this API, to encourage use where suitable and to discourage
>> use where unsuitable.
>>
>>
>> I like that you're considering the balance here. I've been lightly
>> following this thread and want to add my thoughts on keeping crypto and
>> pseudorandomness out of the name of at least one random API intended for
>> general use.
>>
>> For someone who doesn't know or care about the subtleties of insecure or
>> pseudorandom numbers, I'm not sure that the name insecureRandom is
>> effectively much different than badRandom, at least in terms of the
>> information it conveys to non-experts. To Greg's point, that's the opposite
>> of the signal that the API name should suggest because it's what most
>> people should use most of the time. As you say, this API is being designed
>> for general use.
>>
>> There's a cost to adding extra complexity to names, too. I don't think
>> it's far-fetched to suspect that people who find insecureRandom in an
>> autocomplete listing or search will think "Where's the plain random
>> function?"... and then go looking for a community extension that will
>> inevitably provide a trivial alias: func random() { return
>> insecureRandom() }. That's the sort of adoption I'd expect from something
>> for new programmers, like Swift Playgrounds. Someone's introduction to
>> randomness in programming should probably involve no more than a
>> straightforward mapping from the elementary definition, rather than forcing
>> a teaching moment from more advanced math.
>>
>> I think there are better places for caveat information than in the API
>> names themselves; documentation being one clear destination. This is in
>> contrast with Unsafe*Pointer, where the safety element is critical enough
>> to be elevated to be more than caveat-level information. You can go really
>> far and create really cool things before these caveats start to apply.
>> Using randomness as a black box in an intro programming environment seems
>> like a much more common scenario than someone attempting to roll their
>> first crypto by only reading API names and hoping for the best.
>>
>> -Kyle
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/a6d3b662/attachment-0001.html>
>
> ------------------------------
>
> Message: 28
> Date: Wed, 20 Dec 2017 15:51:41 +0100
> From: Karl Wagner <razielim at gmail.com>
> To: Ted Kremenek <kremenek at apple.com>
> Cc: Swift Evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
> Message-ID: <CACD8EF9-6528-4E32-98D4-84B79F917237 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
>> On 20. Dec 2017, at 14:36, Karl Wagner <razielim at gmail.com> wrote:
>>
>>
>>
>>> On 19. Dec 2017, at 23:58, Ted Kremenek via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 <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 <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 <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, 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? 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).
>
> Hah, okay, this was answered. Mail split the threads.
>
> - Karl
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/0271e41a/attachment-0001.html>
>
> ------------------------------
>
> Message: 29
> Date: Wed, 20 Dec 2017 15:56:26 +0100
> From: Karl Wagner <razielim at gmail.com>
> To: swift-evolution <swift-evolution at swift.org>
> Subject: [swift-evolution] [Pitch] @static imports
> Message-ID: <BB3CFA9E-19B7-4B49-AC46-73F03437A569 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> There’s a lot of talk in the non-exhaustive enum discussion about the source transition. So let me suggest a possible solution: @static imports.
>
> Basically, it seems to me like resilience is going to introduce a lot of indirection, both in generated instructions and in the language. I think that making resilience opt-in on a declaration-by-declaration basis would make it difficult for average programmers to get right, so I support the idea of making Swift libraries resilient-by-default with opt-out abilities when it is obvious from the perspective of the library author that it should be so.
>
> However, Apps are not libraries. Whereas libraries are a kind of theoretical block of code, and you naturally want them to be adaptable to different circumstances, Apps are the concrete things which actually use them. They might have a different perspective on what can be allowed to be non-resilient. Just like an App may be built to be compatible with a particular version of a library, I think it’s reasonable for it to be built expecting other “flavours” of the library, too - including a non-resilient flavour. We already kind of have something like this: executables can import modules as @testable, and those modules are required to be built with the “-enable-testing” flag.
>
> My suggestion is that we create a new kind of import mode, "@static import" and some corresponding compiler flag. When you import a module using @static, you tell the compiler that your App requires exactly the module which it is being compiled alongside. When compiling your regular, resilient-by-default Swift libraries with the special flag, they will be transformed to fix them at their current version and provide later stages of the compiler as much information as if it was within the same module (i.e. applying final, @exhaustive, providing complete SIL, etc). App code will not be able to access “internal” members of the @static library (even though the compiler can see them). We might allow the same attribute to be applied to static libraries from C, which can be similarly freed of resilience concerns.
>
> That would help ease code migration - for this and future resilience-related changes - because you’ll basically get the Swift 4 behaviour back for libraries which you control.
>
> // Regular imports. We don’t control these libraries.
> import Foundation
> import UIKit
> // Static imports. We control these; they will be embedded in the final product in some way. Everything is @exhaustive!
> @static import MyDataModel
> @static import SharedUIElements
>
> - Karl
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/9043a75f/attachment-0001.html>
>
> ------------------------------
>
> Message: 30
> Date: Wed, 20 Dec 2017 18:17:36 +0300
> From: "Vladimir.S" <svabox at gmail.com>
> To: Ted Kremenek <kremenek at apple.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
> Message-ID: <fef0e688-713a-509f-4f92-f22cfe4776c2 at gmail.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>> On 20.12.2017 1: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
>>
>> 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?
>
> +0.5.
> I'll give additional +0.5 if 'future' case will be included in proposal.
>
> I still do believe that without 'future' case we are introducing now a bug-generator point of code. For me this is
> obvious. Especially for the moment when Swift 4 code will be converted to Swift 5 and, as I understand, developer will
> see "non-exhaustive enum, add 'default' case" as suggestion during the migration. Instead of "use 'default' or 'future'
> ", so one can think and decide what needed here.
>
> Having a tool('future' case) to express "switch over non-exhaustive enum exhaustively and let me know if new cases
> appear" is IMO a Swifty way, and much better than catching *run-time* bugs when your framework introduced a new enum
> value but you were not able to process it *during the compilation*, because you have 'default' case in switch.
>
> Also, probably I missed this and not sure if this even can work, if framework(module) was compiled with Swift4 and
> contains 'public enum' - will such enum be treated as exhaustive if framework is imported in Swift 5 code? So, it was
> declared without @exchaustive, but for Swift4 exhaustive was the default.
>
> Additionally, I'd like someone answers/comments my question regarding real-world example noted in the proposal
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040053.html).
> Is it really a very rare use-case for embedded framework&enums, and is it really I have to find a way to use lint-like
> tools to check new cases in embedded enum after proposal is implemented? Or use other technique to process all cases of
> enum declared in framework?
>
>>
>> *
>>
>> Is the problem being addressed significant enough to warrant a change to Swift?
>>
>
> Yes, I believe so.
>
>> *
>>
>> Does this proposal fit well with the feel and direction of Swift?
>>
>
> Generally yes, but
> * I don't like @exchaustive as attribute, something like "public sealed enum" or "public enum(final)" IMO is more Swifty
> syntax
> * not safe/dangerous 'default' without able to keep switch exhaustive at compilation time IMO is not Swift-way
>
>> *
>>
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to
>> those?
>>
>> *
>
> Don't know
>
>>
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>
>
> Previous discussions, proposal text and proposal review thread
>
>> Thanks,
>> Ted Kremenek
>> Review Manager
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> ------------------------------
>
> Message: 31
> Date: Wed, 20 Dec 2017 15:55:25 +0000
> From: Xiaodi Wu <xiaodi.wu at gmail.com>
> To: Jens Persson <jens at bitcycle.com>
> Cc: swift-evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Proposal] Random Unification
> Message-ID:
> <CAGY80unOr-Xcy-MiT=U53qYLG3HyQ4ca1zteD4PCx+Wcj_A=iQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> xoroshiro128+ is not a cryptographically secure algorithm and would not be
> incorporated into the Random API, though it is trivial to implement your
> own; the proposal outlines sources of randomness that are cryptographically
> secure.
>
>
> On Wed, Dec 20, 2017 at 09:46 Jens Persson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> I'd like to add a pointer to the information here:
>> http://xoroshiro.di.unimi.it
>>
>> since AFAICS, the xoroshiro128+ generator and the method of "Generating
>> uniform doubles in the unit interval" should probably be implemented in any
>> modern general purpose Random API.
>>
>> Please correct me if there are more up to date (higher quality and faster)
>> general purpose generators and ways of converting UInt64 bit patterns to
>> floating point [0, 1).
>>
>> /Jens
>>
>>
>>
>> On Sun, Dec 3, 2017 at 4:50 AM, Dave Abrahams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I don’t have much to say about this other than that I think the
>>> discussion seems way too narrow, focusing on spelling rather than on
>>> functionality and composability. I consider the “generic random number
>>> library” design to be a mostly-solved problem, in the C++ standard
>>> library (http://en.cppreference.com/w/cpp/numeric/random). Whatever
>>> goes into the Swift standard library does not need to have all those
>>> features right away, but should support being extended into something
>>> having the same general shape. IMO the right design strategy is to *implement
>>> and use* a Swift version of C++’s facilities and only then consider
>>> proposing [perhaps a subset of] that design for standardization in Swift.
>>>
>>> Sent from my iPad
>>>
>>> On Dec 2, 2017, at 5:12 PM, Kyle Murray via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>
>>> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Instead, we ought to make clear to users both the features and the
>>> limitations of this API, to encourage use where suitable and to discourage
>>> use where unsuitable.
>>>
>>>
>>> I like that you're considering the balance here. I've been lightly
>>> following this thread and want to add my thoughts on keeping crypto and
>>> pseudorandomness out of the name of at least one random API intended for
>>> general use.
>>>
>>> For someone who doesn't know or care about the subtleties of insecure or
>>> pseudorandom numbers, I'm not sure that the name insecureRandom is
>>> effectively much different than badRandom, at least in terms of the
>>> information it conveys to non-experts. To Greg's point, that's the opposite
>>> of the signal that the API name should suggest because it's what most
>>> people should use most of the time. As you say, this API is being designed
>>> for general use.
>>>
>>> There's a cost to adding extra complexity to names, too. I don't think
>>> it's far-fetched to suspect that people who find insecureRandom in an
>>> autocomplete listing or search will think "Where's the plain random
>>> function?"... and then go looking for a community extension that will
>>> inevitably provide a trivial alias: func random() { return
>>> insecureRandom() }. That's the sort of adoption I'd expect from
>>> something for new programmers, like Swift Playgrounds. Someone's
>>> introduction to randomness in programming should probably involve no more
>>> than a straightforward mapping from the elementary definition, rather than
>>> forcing a teaching moment from more advanced math.
>>>
>>> I think there are better places for caveat information than in the API
>>> names themselves; documentation being one clear destination. This is in
>>> contrast with Unsafe*Pointer, where the safety element is critical
>>> enough to be elevated to be more than caveat-level information. You can go
>>> really far and create really cool things before these caveats start to
>>> apply. Using randomness as a black box in an intro programming environment
>>> seems like a much more common scenario than someone attempting to roll
>>> their first crypto by only reading API names and hoping for the best.
>>>
>>> -Kyle
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/e53116ed/attachment-0001.html>
>
> ------------------------------
>
> Message: 32
> Date: Tue, 19 Dec 2017 23:17:16 +0000
> From: Ethan Diamond <ethanjdiamond at gmail.com>
> To: swift-evolution at swift.org
> Subject: [swift-evolution] Evaluating the case of an enum with
> associated values as a bool
> Message-ID:
> <CA+TuH2k_Zhmh_+VqH4y1LkJgq-6bF1BgwSV2Sxi2JEgtaEjMPA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello everyone,
>
> One major pain point I've run into with Swift is the inability to evaluate
> the case of an enum that has associated values in a way that just returns a
> bool. We've been given the ability in a switch statement:
>
> enum Enum {
> case a(param: String)
> case b(param: String)
> }
>
> let enumeration: Enum = a(param: "Hi")
> switch enumeration {
> case a:
> // Do something
> case b:
> // Do something
> }
>
> We'e been given the ability in the context of an if statement:
>
> enum Enum {
> case a(param: String)
> case b(param: String)
> }
>
> let enumeration: Enum = a(param: "Hi")
>
> if case .a = enumeration {
> // Do something
> }
>
> But without a basic was of getting a bool for if an enum is a given case,
> here's a list of things I can't do:
>
> *Where statements:*
>
> enum Enum {
> case a(param: Enum2)
> case b(param: Enum2)
> }
>
> enum Enum2 {
> case c(param: String)
> case d(param: String)
> }
>
> let enumeration: Enum = a(param: "Hi")
> switch enumeration {
> case a(let inner) where [INNER CASE IS .c]
> }
>
> ---------
>
> *Filter an array for a certain case:*
>
> Expertly explained by Erica Sadun here:
> http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/
>
> ---------
>
> *Nicely set a UIButton to hidden if an enum is a certain case:*
>
> enum State {
> case `default`
> case searching(results: [Result])
> }
>
> myButton.isHidden = [STATE IS .searching]
>
> ---------
>
> I've run into this issue a ton of times because I tend to represent my
> views a State enums. I haven't seen anything on the board for plans for
> solving this issue, thought. Has there been any discussion about addressing
> it? Ideally I'd be able to do this:
>
> enum Enum {
> case a(param: String)
> case b(param: String)
> }
>
> let enumeration: Enum = a(param: "Hi")
>
> case .a = enumeration // Bool
> case .a(let param) = enumeration // Bool, assigns "Hi" to "param"
>
> Thanks!
> Ethan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171219/f47f9889/attachment-0001.html>
>
> ------------------------------
>
> Message: 33
> Date: Wed, 20 Dec 2017 10:23:44 -0700
> From: Dave DeLong <swift at davedelong.com>
> To: Ted Kremenek <kremenek at apple.com>
> Cc: Swift Evolution <swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums
> Message-ID: <3F301774-306C-4017-BE9A-4A961774F817 at davedelong.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
>> On Dec 19, 2017, at 3:58 PM, Ted Kremenek via swift-evolution <swift-evolution at 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 <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?
>>
> A very strong -1. I do not believe this is the appropriate solution to the problem.
>
> • While the goal of the proposal is to ensure the correctness of *client* code, it does nothing to enforce the correctness of evolving *library* code. As a library author, I can declare a public enum as “exhaustive”, yet still add a new case in the next release. Nothing in the proposal prevents me from doing this, yet doing so would obviously break any clients of my library.
>
> • The name “exhaustive” is misleading for uninformed library authors. An author creates an enum and then thinks “is that all of the cases? Yep! OK, it’s @exhaustive”. Then the next evolution of the library occurs, new cases arise, and now the enum isn’t exhaustive to handle the new cases. So a case gets added, and the formerly-but-not-actually-exhaustive enum is re-stamped as exhaustive, because it once again handles all known cases. “Exhaustive” is not a strong enough name. It does not contain the idea of eternal permanence. Once an enum gets branded as exhaustive and shipped as such, *it can never change*. “Exhaustive” does not imply that, and the lack of that implication will confuse library authors.
>
> • This proposal does not address the case of “publicly exhaustive enums with private cases”. Consider NSExpression.ExpressionType: when creating NSPredicates from format strings, it is easy to create sub-expressions whose expression types are not one of the publicly listed cases. Based on the proposal, NSExpression.ExpressionType would be correctly imported as a non-exhaustive enum. HOWEVER. There is nothing *stopping* a library author from declaring a publicly exhaustive enum (like NSExpression.ExpressionType), but having private cases that get leaked (accidentally or not) past the public barrier and end up in client code. This proposal does nothing to prevent that.
>
> The summary of these objections is this: you fundamentally cannot trust libraries that are not bundled with your application to not change in unexpected ways. Or in other words, if you don’t have the source code, you cannot trust it. And even if you do have the source code, it’s still questionable once you start bridging things in from other languages where this sort of safety is not enforced.
>
> To summarize the summary: Leaving a judgement of “exhaustive or not” up to fallible library authors isn’t safe.
>
> To summarize the summary of the summary: people are a problem.
>> Is the problem being addressed significant enough to warrant a change to Swift?
>>
> Yes, the problem is significant, but in my opinion this is the wrong answer.
>> Does this proposal fit well with the feel and direction of Swift?
>>
> No. Implementing this proposal would give the appearance of safety while still leaving developers subtly but dangerously vulnerable to imperfectly written libraries (ie, all of them).
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>
> I’ve been following the email threads, and I’ve spent years as a library author, both on Apple frameworks and my own personal libraries.
>
> Dave
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/f2c0d30f/attachment-0001.html>
>
> ------------------------------
>
> Message: 34
> Date: Wed, 20 Dec 2017 09:55:01 -0800
> From: Kevin Nattinger <swift at nattinger.net>
> To: Ethan Diamond <ethanjdiamond at gmail.com>
> Cc: swift-evolution at swift.org
> Subject: Re: [swift-evolution] Evaluating the case of an enum with
> associated values as a bool
> Message-ID: <3295775F-455D-4BAF-881A-BC9D2D7728EA at nattinger.net>
> Content-Type: text/plain; charset="utf-8"
>
> 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 <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/ <http://ericasadun.com/2017/01/31/challenge-filtering-associated-value-enumeration-arrays/>
>>
>> ---------
>>
>> Nicely set a UIButton to hidden if an enum is a certain case:
>>
>> enum State {
>> case `default`
>> case searching(results: [Result])
>> }
>>
>> myButton.isHidden = [STATE IS .searching]
>>
>> ---------
>>
>> I've run into this issue a ton of times because I tend to represent my views a State enums. I haven't seen anything on the board for plans for solving this issue, thought. Has there been any discussion about addressing it? Ideally I'd be able to do this:
>>
>> enum Enum {
>> case a(param: String)
>> case b(param: String)
>> }
>>
>> let enumeration: Enum = a(param: "Hi")
>>
>> case .a = enumeration // Bool
>> case .a(let param) = enumeration // Bool, assigns "Hi" to "param"
>>
>> Thanks!
>> Ethan
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171220/b31331e0/attachment-0001.html>
>
> ------------------------------
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> End of swift-evolution Digest, Vol 25, Issue 23
> ***********************************************
More information about the swift-evolution
mailing list