Replacing default with case _ is a commonly rejected proposal, and I do believe it's been discussed since the lowercasing of enum cases.
On Fri, Jun 17, 2016 at 15:55 Tony Allevato via swift-evolution < [email protected]> wrote: > Agreed, it sounds like default should be treated as a contextual keyword > in this case. > > It never even occurred to me that "case _:" would work as a replacement > for default, but it does even today—and now that I've seen it, it makes > total sense. I could definitely get behind a proposal to remove "default" > as a keyword from the language entirely in favor of that. It blends well > with other pattern matching. The only concern I would have would be about > discoverability, but it would be easy to have the compiler emit an error > when it sees default in a switch: "default is unsupported; use case _ > instead." > > > On Fri, Jun 17, 2016 at 1:45 PM E. Maloney via swift-evolution < > [email protected]> wrote: > >> While upgrading to Swift 3, I noticed that I had a few enums with cases >> named .Default that, after being converted to lowercase, now need to be >> rendered using the ugly .`default` notation. >> >> I also noticed something similar while reading the docs for >> NotificationCenter (the NSNotificationCenter replacement, that is, not the >> NotificationCenter that governs the notification center UI); “default” >> can’t be used as a function name without escaping, so the declaration is: >> >> class func `default`() >> >> It seems to me that in the case of function names and enum cases, the >> parser should be able to unambiguously distinguish between the Swift >> keyword “default” and a user-defined name “default”, since IIRC the keyword >> “default” can only be used in parameter lists for generated headers and as >> the last item in a switch statement. >> >> (Perhaps this is also another argument in favor of using “case _:” in >> place of “default:” in a switch statement.) >> >> What do you think? Is there any reason this *wouldn’t* be feasible? >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
