-1 from me too.

Avoiding having to write "default: break" isn't a good justification to 
introduce new syntax. It would make the understanding of case switches harder 
without providing any real benefit for the syntax bloat.

João Pinheiro


> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> -1 from me as well. This suggestion falls into the same category as those 
> about making `else` optional after `guard`, which is repeatedly rejected. 
> Since code is read more often than written, explicit handling of the default 
> case never hurts and can increase clarity. Not having to write `default: 
> break` offers no help in writing correct code and IMO can't justify new 
> syntax or the changing of a well-known control statement.
> 
> On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution 
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> -1 in general.  I want smarter exhaustiveness analysis, but I don’t want to 
> be able to ignore cases that “can’t happen” (so say we, writer of bugs) when 
> they’re clearly in the domain of possible values that can be fed to a 
> switch-case.  Exhaustiveness guarantees wellformedness of a program that does 
> happen to go wrong, and makes it much easier to verify the correctness of the 
> flow of control of the containing block because all points from the switch 
> must be covered.  We also don’t have the type-level tools to convince the 
> checker to allow you to remove unreachable cases.  If it’s really a problem 
> that you are writing default cases everywhere, just bailout in a fatal error 
> with a nice description.  It never hurts.
> 
> ~Robert Widmann
> 
>> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> I know that there is this note in Commonly Rejected Changes 
>> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>:
>> 
>> 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 <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> 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

Reply via email to