[Idea] Allowing most keywords after "."

Douglas_Gregor · 2016-02-26T20:43:48.000Z

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

- Doug

Erica_Sadun · 2016-02-26T23:27:56.000Z

I honestly like upper camel. I know my reasons are linguistically unsupported: static members are not types. But it seems to me that a union type, the fully qualified Type.EnumerationCase specifies the memory layout of how the type is realized.

Still, I like upper camel. I also like upper case for global functions and constants.

-- E, out of step, out of sync

···

On Feb 26, 2016, at 1:43 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

michelf · 2016-02-27T01:12:43.000Z

Another idea is to replace the keyword default with something else. The only place it can occur is within a switch statement, right? We already have a synonym: case _

···

Le 26 févr. 2016 à 15:43, Douglas Gregor via swift-evolution <swift-evolution@swift.org> a écrit :

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

--
Michel Fortin
https://michelf.ca

dwaite · 2016-02-27T14:18:08.000Z

Keywords following dots not requiring backticks also seems a valid option.

More of a meta-comment:
1. Default was actually a poor name choice for an enumeration case given the meaning of ‘default’ in the language. Some might say this name choice is now being escalated
2. Default has always been a restrictive term to have as a keyword, although it is only really required to be considered a keyword in one place

I personally would be fine with switching ‘default’ for ‘else’, as another evolutionator suggested. I don’t remember if this was proposed previously, or if that was only the idea of ‘case _:’, which I’m not really in favor of.

-DW

···

On Feb 26, 2016, at 1:43 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Radek_Pietruszewski · 2016-02-27T13:37:22.000Z

+1, that makes a lot of sense.

Q: Is `case default` in enum context ambiguous? In case I’m forgetting something, `default` is only used in `switch` contexts. So… couldn’t we make the keyword context dependent?

— Radek

···

On 26 Feb 2016, at 21:43, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dduan · 2016-02-27T20:06:55.000Z

One would still need to use back-ticks in the declaration of the case, but
at least uses would be back-

I like it! It solves the particular problem neatly and is a general win in
succinct syntax.

Joel_Lopes_Da_Silva · 2016-02-27T01:37:43.000Z

I agree with Michel that we might as well standardize on "case _" instead of “default”. This way, we wouldn’t even require the back-ticks in the enum case definition in this one case.

But I also like Doug’s proposal, because it could apply nicely to other language keyword (such as switch).

···

--
Joel Lopes Da Silva

On Feb 26, 2016, at 5:12 PM, Michel Fortin via swift-evolution <swift-evolution@swift.org> wrote:

Le 26 févr. 2016 à 15:43, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a écrit :

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

Another idea is to replace the keyword default with something else. The only place it can occur is within a switch statement, right? We already have a synonym: case _

--
Michel Fortin
https://michelf.ca <https://michelf.ca/>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

vmartinelli · 2016-02-27T01:20:53.000Z

+1 upper camel.

-Van

···

On Fri, Feb 26, 2016 at 10:12 PM, Michel Fortin via swift-evolution < swift-evolution@swift.org> wrote:

Le 26 févr. 2016 à 15:43, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> a écrit :

Hi all,

As part of the grand API guidelines discussion, there was a lot of support
for using lowerCamelCase for enum cases, because they are values in Swift.
One unfortunate wrinkle here is that it’s not at all uncommon to have a
case named “Default” for an enumeration. One example pulled randomly from
GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a
“.”, similarly to the way we allow keywords without back-ticks preceding a
‘:’ for argument labels, e.g.:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but
at least uses would be back-tick-free. Thoughts?

Another idea is to replace the keyword default with something else. The
only place it can occur is within a switch statement, right? We already
have a synonym: case _

--
Michel Fortin
https://michelf.ca

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

stephencelis · 2016-02-27T14:05:19.000Z

According to the grammar, `default` is indeed only used in `switch`: The Swift Programming Language: Redirect

I have two thoughts:

1. Is it possible to reconsider reusing another keyword, `else`, as Ruby does?

2. Could the parser scan the leading `.` to prevent the need for escaping cases named "default", or would this unnecessarily complicate the compiler?

···

On Feb 27, 2016, at 8:37 AM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

+1, that makes a lot of sense.

Q: Is `case default` in enum context ambiguous? In case I’m forgetting something, `default` is only used in `switch` contexts. So… couldn’t we make the keyword context dependent?

--
Stephen

Ross_O_Brien · 2016-02-27T14:31:36.000Z

It seems to me that deprecating 'default' should be its own topic, or the
discussion on it will be harder to find, so I'd suggest making a topic
dedicated to that idea, and keeping this one focused on .`keyword`.

Look for the topic: "[Idea] Deprecate the 'default' keyword."

···

On Sat, Feb 27, 2016 at 2:18 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote:

Keywords following dots not requiring backticks also seems a valid option.

More of a meta-comment:
1. Default was actually a poor name choice for an enumeration case given
the meaning of ‘default’ in the language. Some might say this name choice
is now being escalated
2. Default has always been a restrictive term to have as a keyword,
although it is only really required to be considered a keyword in one place

I personally would be fine with switching ‘default’ for ‘else’, as another
evolutionator suggested. I don’t remember if this was proposed previously,
or if that was only the idea of ‘case _:’, which I’m not really in favor of.

-DW

On Feb 26, 2016, at 1:43 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote:

Hi all,

As part of the grand API guidelines discussion, there was a lot of support
for using lowerCamelCase for enum cases, because they are values in Swift.
One unfortunate wrinkle here is that it’s not at all uncommon to have a
case named “Default” for an enumeration. One example pulled randomly from
GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a
“.”, similarly to the way we allow keywords without back-ticks preceding a
‘:’ for argument labels, e.g.:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but
at least uses would be back-tick-free. Thoughts?

- Doug

_______________________________________________
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

Radek_Pietruszewski · 2016-02-27T13:38:17.000Z

I meant “Unless I’m forgetting something”, uh :/

— Radek

···

On 27 Feb 2016, at 14:37, Radosław Pietruszewski <radexpl@gmail.com> wrote:

+1, that makes a lot of sense.

Q: Is `case default` in enum context ambiguous? In case I’m forgetting something, `default` is only used in `switch` contexts. So… couldn’t we make the keyword context dependent?

— Radek

On 26 Feb 2016, at 21:43, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi all,

As part of the grand API guidelines discussion, there was a lot of support for using lowerCamelCase for enum cases, because they are values in Swift. One unfortunate wrinkle here is that it’s not at all uncommon to have a case named “Default” for an enumeration. One example pulled randomly from GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a “.”, similarly to the way we allow keywords without back-ticks preceding a ‘:’ for argument labels, e.g.:

  func dispatch(priority priority:

  dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but at least uses would be back-tick-free. Thoughts?

  - Doug

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Radek_Pietruszewski · 2016-02-27T16:38:46.000Z

I do like `else` — it still reads naturally with the list of cases, maybe is even superior to `default`.

I think part of `default`s appeal (vs just removing it and mandating `case _`), is that default is familiar and used in a lot of languages (I don’t know of anything but Ruby that would use else in this context)

Still, `else` doesn't require understanding of wildcards or other pattern matching syntax details, which is good on this axis, and is also familiar, just isn’t used in this context in most languages.

2. Could the parser scan the leading `.` to prevent the need for escaping cases named "default", or would this unnecessarily complicate the compiler?

I’m sorry, I’m confused — I thought that was the whole point of the OP’s idea?

— Radek

···

On 27 Feb 2016, at 15:05, Stephen Celis <stephen.celis@gmail.com> wrote:

On Feb 27, 2016, at 8:37 AM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

+1, that makes a lot of sense.

Q: Is `case default` in enum context ambiguous? In case I’m forgetting something, `default` is only used in `switch` contexts. So… couldn’t we make the keyword context dependent?

According to the grammar, `default` is indeed only used in `switch`: The Swift Programming Language: Redirect

I have two thoughts:

1. Is it possible to reconsider reusing another keyword, `else`, as Ruby does?

2. Could the parser scan the leading `.` to prevent the need for escaping cases named "default", or would this unnecessarily complicate the compiler?

--
Stephen

Joe_Groff · 2016-02-27T20:14:48.000Z

Stephen Celis via swift-evolution

···

<swift-evolution@swift.org> wrote:

1. Is it possible to reconsider reusing another keyword, `else`, as Ruby does?

C needed a different keyword to avoid needing lookahead, since 'if (foo);
else' could either be part of an if statement or an if statement followed
by an 'else:' label otherwise. That's not fundamentally a problem for us.
'default' is interesting as an identifier name in general so I think it's
worth considering giving it back.

-Joe

Chris_Lattner · 2016-02-28T05:58:55.000Z

“default” isn’t core to Doug’s proposal. There are other keywords that are problematic as well, particularly as we start importing more and more global constants as members (because of https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md\).

Besides that, we’ve talked about default before: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md We could definitely make it context sensitive within refutable patterns (or something) but this doesn’t define away the need for something like Doug’s proposal.

-Chris

···

On Feb 27, 2016, at 6:05 AM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 27, 2016, at 8:37 AM, Radosław Pietruszewski via swift-evolution <swift-evolution@swift.org> wrote:

+1, that makes a lot of sense.

Q: Is `case default` in enum context ambiguous? In case I’m forgetting something, `default` is only used in `switch` contexts. So… couldn’t we make the keyword context dependent?

According to the grammar, `default` is indeed only used in `switch`: The Swift Programming Language: Redirect

I have two thoughts:

1. Is it possible to reconsider reusing another keyword, `else`, as Ruby does?

2. Could the parser scan the leading `.` to prevent the need for escaping cases named "default", or would this unnecessarily complicate the compiler?

cryo · 2016-02-27T22:39:39.000Z

I’m with Erica on this one. Enum cases to me feel like datatype constructors, and not as members as such (for instance enum Tree { Leaf, Branch }). It makes them stand out more when deconstructing in switch statements. I think it’s unfortunate to switch to lowerCamel.

—Sune

···

On 27 Feb 2016, at 00:27, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

I honestly like upper camel. I know my reasons are linguistically unsupported: static members are not types. But it seems to me that a union type, the fully qualified Type.EnumerationCase specifies the memory layout of how the type is realized.

Still, I like upper camel. I also like upper case for global functions and constants.

-- E, out of step, out of sync

hlovatt · 2016-02-28T02:54:36.000Z

+1 for lower camel & case _

···

On Saturday, 27 February 2016, Joel Lopes Da Silva via swift-evolution < swift-evolution@swift.org> wrote:

I agree with Michel that we might as well standardize on "case _" instead
of “default”. This way, we wouldn’t even require the back-ticks in the enum
case definition in this one case.

But I also like Doug’s proposal, because it could apply nicely to other
language keyword (such as switch).

--
Joel Lopes Da Silva

On Feb 26, 2016, at 5:12 PM, Michel Fortin via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Le 26 févr. 2016 à 15:43, Douglas Gregor via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> a écrit :

Hi all,

As part of the grand API guidelines discussion, there was a lot of support
for using lowerCamelCase for enum cases, because they are values in Swift.
One unfortunate wrinkle here is that it’s not at all uncommon to have a
case named “Default” for an enumeration. One example pulled randomly from
GitHub:

enum DispatchQOS {
  case UserInteractive
  case UserInitiated
  case Default
  case Utility
  case Background
}

If we’re lowerCamelCasting enum cases, this becomes:

enum DispatchQOS {
  case userInteractive
  case userInitiated
  case `default`
  case utility
  case background
}

Note the back-ticks, which are also needed at the call site:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

We could allow one to refer to keywords without back-ticks following a
“.”, similarly to the way we allow keywords without back-ticks preceding a
‘:’ for argument labels, e.g.:

func dispatch(priority priority:

dispatch(priority: .`default`) { … }

One would still need to use back-ticks in the declaration of the case, but
at least uses would be back-tick-free. Thoughts?

Another idea is to replace the keyword default with something else. The
only place it can occur is within a switch statement, right? We already
have a synonym: case _

--
Michel Fortin
https://michelf.ca

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

stephencelis · 2016-02-27T16:43:25.000Z

I was pre-coffee and my internal parser/scanner was buggy. Sorry!

Stephen

···

On Feb 27, 2016, at 11:38 AM, Radosław Pietruszewski <radexpl@gmail.com> wrote:

2. Could the parser scan the leading `.` to prevent the need for escaping cases named "default", or would this unnecessarily complicate the compiler?

I’m sorry, I’m confused — I thought that was the whole point of the OP’s idea?

stephencelis · 2016-02-28T18:24:25.000Z

Understood and agreed! I'm definitely in favor of the proposal as it stands and did not mean to derail the conversation.

Stephen

···

On Feb 28, 2016, at 12:58 AM, Chris Lattner <clattner@apple.com> wrote:

“default” isn’t core to Doug’s proposal. There are other keywords that are problematic as well, particularly as we start importing more and more global constants as members (because of https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md\).

Besides that, we’ve talked about default before: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md We could definitely make it context sensitive within refutable patterns (or something) but this doesn’t define away the need for something like Doug’s proposal.

Brent_Royal-Gordon · 2016-02-29T12:20:41.000Z

Besides that, we’ve talked about default before: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

Chris, my understanding is that the commonly proposed list is not a ban on certain topics, but merely a statement that those topics have been considered before and anyone reintroducing the topic should be certain they have something new to say. Surely "This other change we're implementing makes this syntactically ambiguous" would qualify?

···

--
Brent Royal-Gordon
Architechies

Chris_Lattner · 2016-03-01T05:40:09.000Z

Besides that, we’ve talked about default before: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

Chris, my understanding is that the commonly proposed list is not a ban on certain topics, but merely a statement that those topics have been considered before and anyone reintroducing the topic should be certain they have something new to say.

Yep, absolutely.

Surely "This other change we're implementing makes this syntactically ambiguous" would qualify?

Yes it does. The problem is (and Doug’s email didn’t make this clear enough…) that default isn’t the only problem here. There are several different keywords that cause conflicts.

In any case, I’m sorry if my response was overly strong and negative. I didn’t intend to curtail a positive discussion!

-Chris

···

On Feb 29, 2016, at 4:20 AM, Brent Royal-Gordon <brent@architechies.com> wrote: