[Pitch] Allow use of the name "default" for enum cases and function names


(E. Maloney) #1

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?


(Jacob Bandes-Storch) #2

Isn't this already done, at least for enum cases? I'm pretty sure I've seen
discussion of this before, and I thought it might've gotten implemented.

···

On Fri, Jun 17, 2016 at 1:45 PM E. Maloney via swift-evolution < swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Allevato) #3

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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(E. Maloney) #4

It looks like it’s not-quite-done for enum cases in Xcode 8: You can’t declare an enum with a case named “default” without escaping the name. However, it looks like you can refer to an enum case named “default” using simply “.default”, which I didn’t realize. (I had mistakenly assumed the escaping rule would be consistent between the enum declaration and the use-site. Silly me.)

Either way, it would be great if you could use “default” as a name universally, especially since it’s a pretty common name to want to use.

···

On Jun 17, 2016, at 1:50 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:

Isn't this already done, at least for enum cases? I'm pretty sure I've seen discussion of this before, and I thought it might've gotten implemented.
On Fri, Jun 17, 2016 at 1:45 PM E. Maloney via swift-evolution <swift-evolution@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Rimmington) #5

Tony Allevato wrote:

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.

Chris Lattner wrote:

`default` is widely used, `case _` is too magical, and `default` is widely
precedented in many C family languages.

<https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>

-- Ben


(Xiaodi Wu) #6

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@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@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@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


(Xiaodi Wu) #7

Right. I don't think there's any plan currently to allow enum case
declarations of reserved keywords without backticks. The reasoning, IIUC,
was that use sites were far more common and in that context cases could be
distinguished by the leading dot. By contrast, declarations are made only
once.

FWIW, this is implemented for all keywords and not just `default`, so
`.class` or even `.case` should work right now too. It seemed like the core
team wanted general solutions that can be implemented for all keywords, and
a general solution for declaring enum cases without backticks is probably
not possible, I think?

···

On Fri, Jun 17, 2016 at 16:57 E. Maloney via swift-evolution < swift-evolution@swift.org> wrote:

It looks like it’s not-quite-done for enum cases in Xcode 8: You can’t
declare an enum with a case named “default” without escaping the name.
However, it looks like you can refer to an enum case named “default” using
simply “.default”, which I didn’t realize. (I had mistakenly assumed the
escaping rule would be consistent between the enum declaration and the
use-site. Silly me.)

Either way, it would be great if you could use “default” as a name
universally, especially since it’s a pretty common name to want to use.

> On Jun 17, 2016, at 1:50 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > wrote:
>
> Isn't this already done, at least for enum cases? I'm pretty sure I've
seen discussion of this before, and I thought it might've gotten
implemented.
> On Fri, Jun 17, 2016 at 1:45 PM E. Maloney via swift-evolution < > swift-evolution@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@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


(Vladimir) #8

Also didn't know `case _: ` works as `default`. So we have 2 things that do exactly the same. Agree, that leaving `case _:` and removing 'default' will increase the consistency of the language. I even think `case _:` is better than `default` in any way. Don't agree that this case confuse anybody : each language has its own special syntax features. If one will teach Swift as first language - no problems at all, `case _: ` construction is very simple and understandable. If one will teach Swift as next language, so this person is professional enough to use `case _:` in Swift instead of `default`, don't see any tragedy here.
But yes, I see that this is "commonly rejected proposal", so OK.

···

On 17.06.2016 23:54, Tony Allevato via swift-evolution 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@swift.org <mailto:swift-evolution@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@swift.org <mailto: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


(E. Maloney) #9

I still don’t see why not. What could possibly come after the ‘case’ in an enum declaration other than the name of the enum case itself?

To my knowledge, the only modifier of an enum case is the “indirect” modifier, but that always comes *before* the “case” keyword, so there’s no ambiguity there.

···

On Jun 17, 2016, at 3:07 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

Right. I don't think there's any plan currently to allow enum case declarations of reserved keywords without backticks. The reasoning, IIUC, was that use sites were far more common and in that context cases could be distinguished by the leading dot. By contrast, declarations are made only once.

FWIW, this is implemented for all keywords and not just `default`, so `.class` or even `.case` should work right now too. It seemed like the core team wanted general solutions that can be implemented for all keywords, and a general solution for declaring enum cases without backticks is probably not possible, I think?


(Tony Allevato) #10

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 :slight_smile:

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@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@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@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@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