[swift-evolution] Pitch: disallow `()` from Switch statement case satisfaction

Chris Lattner clattner at apple.com
Thu Oct 13 10:31:30 CDT 2016


> On Oct 13, 2016, at 4:26 AM, Alex Blewitt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On 13 Oct 2016, at 11:06, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On 11 Oct 2016, at 19:43, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> I thought this was long gone but today I found out it is still legal:
>>> 
>>> switch i {
>>> case 4 ... 6: ()
>>> case 3: print("Here")
>>> default: break
>>> }
>>> 
>>> Is there a motivating factor for keeping this in the language? The compiler picks up on Void and emits an error. You'd think () would produce the same results but it doesn't.
>>> 
>>> — Erica
>> 
>> Hopefully I'm not the only one but… how are we supposed to be doing this? Because () is exactly what I've been using the entire time for cases that I want to ignore (or are handled in code outside the switch). I'm going to have a few dozen files to edit if there's something else I'm supposed to be using… 
> 
> You can have a 'break' there, which is equivalent to a nop but without a return value. Whether that's what you're supposed to do or not is a different issue :)

Right, I’d recommend using “break” for a case that you’re intentionally ignoring.  That communicates clearly to someone maintaining the code that you thought about it and are intentionally ignoring it (or bailing out before other cases could match it).

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161013/aa9e0ee4/attachment.html>


More information about the swift-evolution mailing list