In my code, I ‘use’ the forced coverage of the case’s to be reminded of area’s
where I have to update my code when the enum’s change.
I.e. choosing for an enum solution is partly motivated by the factor that
case-coverage has to be complete.
I’d hate to miss that.
Rien.
> On 03 Oct 2016, at 12:55, Adrian Zubarev <adrian.zuba...@devandartist.com>
> wrote:
>
> This is clearly not a huge issue to solve, but a pitch is a pitch.
>
> From Swift book we know this:
>
> Switch Statements Must Be Exhaustive
>
> In Swift, every possible value of the control expression’s type must match
> the value of at least one pattern of a case. When this simply isn’t feasible
> (for instance, when the control expression’s type is Int), you can include a
> default case to satisfy the requirement.
> Even for enum values an optional default would mean that you don’t care about
> the other cases in your current switch, which basically again would be
> another useless nop.
>
> enum A {
> case a, b, c
> }
>
> var value = A.a
>
> switch value {
>
> case .a:
> value = A.b
>
> default:
> () // I don't care
> }
>
> // Do something else
>
> switch value {
>
> case .b:
> value = A.c
>
> default:
> () // I don't care
> }
>
> Sure the error message is there to notify you that you might forget to handle
> some case, but how we handle that specific case is still up to us.
>
> I’d really like to know what could be dangerous here when default would be
> optional.
>
> I can’t tell if this would have some impact on the ABI or not. I’d say it’s
> additive because it doesn’t break any existing code but removes an existing
> restriction.
>
> The next thought might be an overkill (or maybe not):
>
> How about making default optional everywhere + introducing a new attribute
> that allows the optional default on that particular enum, but by default
> every current existing enum should be handled exhaustively.
>
> Bikeshedding:
>
> enum A {
> case a, b, c
> }
>
> var value = A.a
>
> switch value {
>
> case .a:
> value = A.b
>
> } // Error: switch must be exhaustive, consider adding a default clause
>
> // VS:
>
> @discardableCase enum B {
> case d, e, f
> }
>
> let anotherValue = B.d
>
> switch anotherValue {
>
> case .d:
> // Do something
>
> case .e:
> // Do something else
>
> } // Just fine; We don't care here about `.f`
>
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 3. Oktober 2016 um 12:28:58, Rien (r...@balancingrock.nl) schrieb:
>
>> On non-enum values, yes I could support this. However I do not see this as a
>> big enough issue.
>> On enum values? no way….
>>
>> Btw this would get rid of:
>>
>> let bytesSend = send(…) // returns an Int
>>
>> switch bytesSend {
>> case Int.min ... -1: {…}
>> case 0: {…}
>> case 1 ... Int.max: {…}
>> default: break // <<<<<< Imposible
>> }
>>
>>
>>
>>
>> > On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution
>> > <swift-evolution@swift.org> wrote:
>> >
>> > I know that there is this note in Commonly Rejected Changes:
>> >
>> > Remove support for default: in switch and just use case _:: default is
>> > widely used, case _ is too magical, and default is widely precedented in
>> > many C family languages.
>> > I really like to use the switch instead of if case for pattern matching,
>> > just because it’s neat block design. I do not want to remove default from
>> > switches because it’s a must have and powerful feature.
>> >
>> > I’d like to know why switches must be exhaustive.
>> >
>> > switch someValue {
>> >
>> > case …:
>> > // Do something
>> >
>> > case …:
>> > // Do something else
>> >
>> > default:
>> > () // useless nop; do nothing when no pattern matched
>> > }
>> >
>> > // VS:
>> >
>> > if case … {
>> >
>> > } else if case … {
>> >
>> > } else if case … {
>> >
>> > } // No need for `else`
>> >
>> > Can’t we make default optional, or at least on non-enum values?
>> >
>> >
>> >
>> >
>> > --
>> > Adrian Zubarev
>> > Sent with Airmail
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution@swift.org
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
