Thanks to you (and Ben Remmington on another thread) for pointing that out—it's been a while since I read that doc so I've forgotten specific cases :)
I'm lukewarm about C family precedent necessarily constraining us in a world where one compiler diagnostic can teach developers the Swift way of doing it, but I don't want to rehash long-settled debates in the face of more important changes. On Fri, Jun 17, 2016 at 2:31 PM Xiaodi Wu <[email protected]> wrote: > 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
