[swift-evolution] [Pitch] Allow use of the name "default" for enum cases and function names
Tony Allevato
allevato at google.com
Fri Jun 17 16:32:21 CDT 2016
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 <xiaodi.wu at gmail.com> 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 <
> swift-evolution at swift.org> 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 <
>> swift-evolution at swift.org> 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
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160617/03269475/attachment.html>
More information about the swift-evolution
mailing list