<div dir="ltr">There has been a little discussion on this before, and I think there's a need for something along these lines - I've written code where I've used 'guard' to ensure that an Int was within a certain range, and then performed a switch on the Int, requiring an ugly-looking 'default: fatalError()' at the end to dismiss the warning.<div><br></div><div>But exhaustive switches are also useful.</div><div><br></div><div>There was an elegant suggestion that we apply '?' and '!' to the switch keyword. Basically:</div><div>- 'switch <expression>' is exhaustive across values and enum states and the compiler will warn you if you omit an enum state or default case.</div><div>- 'switch? <expression>' is not exhaustive but the compiler should still check the flow (to ensure all paths return values, that kind of thing).</div><div>- 'switch! <expression>' is not exhaustive but it assumes one of the cases will match, and crashes otherwise.</div><div><br></div><div>Basically, switch wouldn't change, but appending the '?' is equivalent to typing 'default: break' as your final case, and appending '!' is equivalent to typing 'default: fatalError()' as your final case. The meanings are roughly analogous to their meanings for Optionals, so hopefully there wouldn't be much confusion.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 3, 2016 at 11:55 AM, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class="m_2037290431548325344bloop_markdown"><p>This is clearly not a huge issue to solve, but a pitch is a pitch.</p>
<p>From Swift book we know this:</p>
<blockquote>
<p><strong>Switch Statements Must Be Exhaustive</strong></p>
<p>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.</p>
</blockquote>
<p>Even for enum values an optional <code>default</code> would mean that you don’t care about the other cases in your current switch, which basically again would be another useless nop.</p>
<pre><code class="m_2037290431548325344swift">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
}
</code></pre>
<p>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.</p>
<p>I’d really like to know what could be dangerous here when <code>default</code> would be optional.</p>
<p>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. </p>
<hr>
<p>The next thought might be an overkill (or maybe not):</p>
<p>How about making <code>default</code> optional everywhere + introducing a new attribute that allows the optional <code>default</code> on that particular enum, but by default every current existing enum should be handled exhaustively.</p>
<p>Bikeshedding:</p>
<pre><code class="m_2037290431548325344swift">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`
</code></pre>
<p></p></div><div class="m_2037290431548325344bloop_original_html"><span class=""><div id="m_2037290431548325344bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="m_2037290431548325344bloop_sign_1475490682107675136" class="m_2037290431548325344bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br></span><div><div class="h5"><p class="m_2037290431548325344airmail_on">Am 3. Oktober 2016 um 12:28:58, Rien (<a href="mailto:rien@balancingrock.nl" target="_blank">rien@balancingrock.nl</a>) schrieb:</p> <blockquote type="cite" class="m_2037290431548325344clean_bq"><span><div><div></div><div>On non-enum values, yes I could support this. However I do not see this as a big enough issue.
<br>On enum values? no way….
<br>
<br>Btw this would get rid of:
<br>
<br> let bytesSend = send(…) // returns an Int
<br>
<br> switch bytesSend {
<br> case Int.min ... -1: {…}
<br> case 0: {…}
<br> case 1 ... Int.max: {…}
<br> default: break // <<<<<< Imposible
<br> }
<br>
<br>
<br>
<br>
<br>> On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:
<br>>
<br>> I know that there is this note in Commonly Rejected Changes:
<br>>
<br>> 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.
<br>> 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.
<br>>
<br>> I’d like to know why switches must be exhaustive.
<br>>
<br>> switch someValue {
<br>>
<br>> case …:
<br>> // Do something
<br>>
<br>> case …:
<br>> // Do something else
<br>>
<br>> default:
<br>> () // useless nop; do nothing when no pattern matched
<br>> }
<br>>
<br>> // VS:
<br>>
<br>> if case … {
<br>>
<br>> } else if case … {
<br>>
<br>> } else if case … {
<br>>
<br>> } // No need for `else`
<br>>
<br>> Can’t we make default optional, or at least on non-enum values?
<br>>
<br>>
<br>>
<br>>
<br>> --
<br>> Adrian Zubarev
<br>> Sent with Airmail
<br>>
<br>> ______________________________<wbr>_________________
<br>> swift-evolution mailing list
<br>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>
<br>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a>
<br>
<br></div></div></span></blockquote></div></div></div><div class="m_2037290431548325344bloop_markdown"><p></p></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>