Hi all,
I am very much in favor of ‘switch x { … unknown: … }’ to express that I am
expecting the cases to be complete at compile time so that I get notified when
compiling against a newer version of the library where the enum has been
extended.
I consider not being able to test this a minor p
> On Dec 23, 2017, at 4:15 PM, Slava Pestov via swift-evolution
> wrote:
>
>
>
>> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution
>> wrote:
>>
>>
>>> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution
>>> wrote:
>>>
>>> What are your thoughts on `final switc
Hi Thomas,
I see what you mean now. I think in this case I would prefer to just spell this
as ‘switch x { … unknown: … }’ vs ‘switch x { … default: … }’. But yes, a few
people have signaled support for such a feature and I think it’s worth
discussing.
Slava
> On Dec 23, 2017, at 4:27 PM, Thom
Hi Slava,
I think we may be referring to different things. For whatever it’s worth, I
agree with your reasoning on all the points you brought up. I also don’t think
having a 'default: fatalError()’ case is a good idea because then a library
change can cause crashes in a running version of an ap
> On Dec 23, 2017, at 3:47 PM, Thomas Roughton via swift-evolution
> wrote:
>
>
> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution
> mailto:swift-evolution@swift.org>> wrote:
>>
>> What are your thoughts on `final switch` as a way to treat any enum as
>> exhaustible?
>> https:/
> On 24/12/2017, at 9:40 AM, Cheyo Jimenez via swift-evolution
> wrote:
>
> What are your thoughts on `final switch` as a way to treat any enum as
> exhaustible?
> https://dlang.org/spec/statement.html#FinalSwitchStatement
> ___
> swift-evolution mai
> On Dec 21, 2017, at 9:49 AM, Ignacio Soto via swift-evolution
> wrote:
>
> I think I speak for the entire Swift community when I say that Swift's enums,
> together with the ability to switch over them exhaustively and having
> compile-time guarantees, is one of the best features in Swift.
> On Dec 21, 2017, at 10:33 AM, Jordan Rose via swift-evolution
> wrote:
>
> The main blocker was that such a case becomes untestable (see also "Testing
> invalid cases").
You can always make it testable through appropriate factoring—for example, have
the `future` case call a helper function,
I think you make a fair point here - either case is currently untestable in a
non-exhaustive enum.
Perhaps this pushes harder on the “future” case and a way we can test this in
Unit Tests when we @testable import other frameworks to simulate an additional
case.
> On 22 Dec 2017, at 5:36 am, Ke
>> [...]
>
> Hi, Nacho. This is discussed in the proposal as "'future' cases" under
> "Alternatives considered". The main blocker was that such a case becomes
> untestable (see also "Testing invalid cases"). That didn't seem like an
> acceptable state of affairs to me or to the people I had ori
[Proposal:
https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md]
> On Dec 21, 2017, at 09:49, Ignacio Soto via swift-evolution
> wrote:
>
> I think I speak for the entire Swift community when I say that Swift's enums,
> together with the ability to switc
> What I’m proposing is that we introduce a new keyword, unknown (or a better
> name), that serves as a way to handle cases that aren’t yet known, but not
> those that are.
Afaics, the best this could do is helping when a compiled library using
another, updated library with new cases in a switc
I think I speak for the entire Swift community when I say that Swift's enums,
together with the ability to switch over them exhaustively and having
compile-time guarantees, is one of the best features in Swift. I'm regularly
annoyed by this when writing other languages like Java and JS (default:
13 matches
Mail list logo
