<div dir="ltr">There has been a little discussion on this before, and I think there&#39;s a need for something along these lines - I&#39;ve written code where I&#39;ve used &#39;guard&#39; to ensure that an Int was within a certain range, and then performed a switch on the Int, requiring an ugly-looking &#39;default: fatalError()&#39; 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 &#39;?&#39; and &#39;!&#39; to the switch keyword. Basically:</div><div>- &#39;switch &lt;expression&gt;&#39; is exhaustive across values and enum states and the compiler will warn you if you omit an enum state or default case.</div><div>- &#39;switch? &lt;expression&gt;&#39; is not exhaustive but the compiler should still check the flow (to ensure all paths return values, that kind of thing).</div><div>- &#39;switch! &lt;expression&gt;&#39; is not exhaustive but it assumes one of the cases will match, and crashes otherwise.</div><div><br></div><div>Basically, switch wouldn&#39;t change, but appending the &#39;?&#39; is equivalent to typing &#39;default: break&#39; as your final case, and appending &#39;!&#39; is equivalent to typing &#39;default: fatalError()&#39; as your final case. The meanings are roughly analogous to their meanings for Optionals, so hopefully there wouldn&#39;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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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&#39;t care
}

// Do something else  

switch value {
     
case .b:
    value = A.c
     
default:
    () // I don&#39;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&#39;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 // &lt;&lt;&lt;&lt;&lt;&lt; Imposible
<br>        }
<br>
<br>
<br>
<br>
<br>&gt; On 03 Oct 2016, at 12:14, Adrian Zubarev via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:
<br>&gt;  
<br>&gt; I know that there is this note in Commonly Rejected Changes:
<br>&gt;  
<br>&gt; 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>&gt; 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>&gt;  
<br>&gt; I’d like to know why switches must be exhaustive.  
<br>&gt;  
<br>&gt; switch someValue {
<br>&gt;       
<br>&gt; case …:
<br>&gt;     // Do something
<br>&gt;       
<br>&gt; case …:
<br>&gt;     // Do something else
<br>&gt;  
<br>&gt; default:   
<br>&gt;     () // useless nop; do nothing when no pattern matched
<br>&gt; }
<br>&gt;  
<br>&gt; // VS:
<br>&gt;  
<br>&gt; if case … {
<br>&gt;       
<br>&gt; } else if case … {
<br>&gt;       
<br>&gt; } else if case … {
<br>&gt;       
<br>&gt; } // No need for `else`
<br>&gt;  
<br>&gt; Can’t we make default optional, or at least on non-enum values?
<br>&gt;  
<br>&gt;  
<br>&gt;  
<br>&gt;  
<br>&gt; --  
<br>&gt; Adrian Zubarev
<br>&gt; Sent with Airmail
<br>&gt;  
<br>&gt; ______________________________<wbr>_________________
<br>&gt; swift-evolution mailing list
<br>&gt; <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>
<br>&gt; <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>