[Idea] Deprecate the 'default' keyword.

Ross_O_Brien · February 27, 2016, 2:31pm

Let's make this a topic of its own.

As mentioned recently in the '[Idea] Allowing most keywords after "."'
thread, the 'default' keyword is only used as a keyword in switch
statements, where it's synonymous with 'case _:'.
It's also the kind of word which appears commonly in enums.

So, why do we need to keep it as a keyword?

Disadvantages: there would be some breaking of code, but a migration tool
should have little difficulty replacing 'default:' with 'case _:' in all
cases.

Alternatives: replace 'default' with 'else'.

timv · February 27, 2016, 3:57pm

I kinda like Haskell’s “otherwise”, and it’s move obvious what it means than “default” from an English language point of view.

···

Let's make this a topic of its own.

As mentioned recently in the '[Idea] Allowing most keywords after "."' thread, the 'default' keyword is only used as a keyword in switch statements, where it's synonymous with 'case _:'.
It's also the kind of word which appears commonly in enums.

So, why do we need to keep it as a keyword?

Disadvantages: there would be some breaking of code, but a migration tool should have little difficulty replacing 'default:' with 'case _:' in all cases.

Alternatives: replace 'default' with 'else'._______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dduan · February 27, 2016, 7:17pm

Ross O'Brien via swift-evolution <swift-evolution@...> writes:

Alternatives: replace 'default' with 'else'.

Unlike dropping the 'default' keyword (not commenting on that here), this
alternative idea adds very little value to warrant a change to the language.
'default' is clear and well-understood as is.

salutis · February 27, 2016, 8:52pm

+1 (as always) for replacing "default" with "case _".

It's consistent with other uses of "_", teaches about the concept of "_", simplifies the language vocabulary, frees "default" to be used as a case and it also looks better. :)

R+

···

Sent from my iPhone

On 27 Feb 2016, at 15:31, Ross O'Brien via swift-evolution <swift-evolution@swift.org> wrote:

Let's make this a topic of its own.

As mentioned recently in the '[Idea] Allowing most keywords after "."' thread, the 'default' keyword is only used as a keyword in switch statements, where it's synonymous with 'case _:'.
It's also the kind of word which appears commonly in enums.

So, why do we need to keep it as a keyword?

Disadvantages: there would be some breaking of code, but a migration tool should have little difficulty replacing 'default:' with 'case _:' in all cases.

Alternatives: replace 'default' with 'else'.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

jtbandes · February 27, 2016, 9:06pm

Previous discussion:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001393.html

···

On Sat, Feb 27, 2016 at 12:52 PM, Rudolf Adamkovic via swift-evolution < swift-evolution@swift.org> wrote:

+1 (as always) for replacing "default" with "case _".

It's consistent with other uses of "_", teaches about the concept of "_",
simplifies the language vocabulary, frees "default" to be used as a case
and it also looks better. :)

R+

Sent from my iPhone

> On 27 Feb 2016, at 15:31, Ross O'Brien via swift-evolution < > swift-evolution@swift.org> wrote:
>
> Let's make this a topic of its own.
>
> As mentioned recently in the '[Idea] Allowing most keywords after "."'
thread, the 'default' keyword is only used as a keyword in switch
statements, where it's synonymous with 'case _:'.
> It's also the kind of word which appears commonly in enums.
>
> So, why do we need to keep it as a keyword?
>
> Disadvantages: there would be some breaking of code, but a migration
tool should have little difficulty replacing 'default:' with 'case _:' in
all cases.
>
> Alternatives: replace 'default' with 'else'.
> _______________________________________________
> 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

xwu · February 27, 2016, 10:42pm

Not sure if you're directing the follow-up questions to me in
particular. But, speaking only as some guy on a mailing list, my two
cents are:

If the proposal to allow dot-keywords succeeds, then I cannot see any
particular reason why reprising this discussion will lead anywhere
other than re-rejection, since the key justification for re-evaluation
will be moot. If the proposal to allow dot-keywords fails, then as
Brent said we may have a changed calculus due to the switch to
lowercase for enum cases and option set values. Until that plays out
it seems to me this discussion may be premature.

FWIW, that a change in naming convention puts commonly used names in
conflict with reserved keywords is an insight that I don't remember
being raised in the original discussion about case conventions for
enum cases; I wonder if all involved in that discussion might have
changed their minds if this had been pointed out more prominently
earlier.

···

On Sat, Feb 27, 2016 at 3:32 PM, Ross O'Brien via swift-evolution <swift-evolution@swift.org> wrote:

Xiaodi, thanks for pointing that out. That's an unfortunate oversight.

Following on from Brent's comments, then... the proposal as is will probably
be rejected as before. Since I seem to have acted too quickly in submitting
it, do you think I should close it, or leave it so it can be edited? Would
editing it be as simple as pointing its link to the discussion on allowing
dot-keywords (since, apart from Tim's suggestion of Haskell's "otherwise",
everything argued in this thread is in that one), or is more substantial
editing required?

--Ross

On Sat, Feb 27, 2016 at 9:06 PM, Jacob Bandes-Storch via swift-evolution > <swift-evolution@swift.org> wrote:

Previous discussion:

[swift-evolution] Remove default case in switch-case

On Sat, Feb 27, 2016 at 12:52 PM, Rudolf Adamkovic via swift-evolution >> <swift-evolution@swift.org> wrote:

+1 (as always) for replacing "default" with "case _".

It's consistent with other uses of "_", teaches about the concept of "_",
simplifies the language vocabulary, frees "default" to be used as a case and
it also looks better. :)

R+

Sent from my iPhone

> On 27 Feb 2016, at 15:31, Ross O'Brien via swift-evolution >>> > <swift-evolution@swift.org> wrote:
>
> Let's make this a topic of its own.
>
> As mentioned recently in the '[Idea] Allowing most keywords after "."'
> thread, the 'default' keyword is only used as a keyword in switch
> statements, where it's synonymous with 'case _:'.
> It's also the kind of word which appears commonly in enums.
>
> So, why do we need to keep it as a keyword?
>
> Disadvantages: there would be some breaking of code, but a migration
> tool should have little difficulty replacing 'default:' with 'case _:' in
> all cases.
>
> Alternatives: replace 'default' with 'else'.
> _______________________________________________
> 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

_______________________________________________
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

xwu · February 27, 2016, 8:17pm

This idea (replacing default) has already been proposed previously and
rejected. See:

github.com

apple/swift-evolution/blob/main/commonly_proposed.md

# Commonly Rejected Changes 

This is a list of changes to the Swift language that are frequently proposed but that are unlikely to be accepted.  If you're interested in pursuing something in this space, please familiarize yourself with the discussions that we have already had.  In order to bring one of these topics up, you'll be expected to add new information to the discussion, not just to say, "I really want this" or "this exists in some other language and I liked it there".

Additionally, proposals for out-of-scope changes will not be scheduled for review. The [readme file](README.md) identifies a list of priorities for the next major release of Swift, and the [dashboard](https://www.swift.org/swift-evolution/) includes a list of changes that have been rejected after a formal review.

Several of the discussions below refer to "C family" languages. This is intended to mean the extended family of languages that resemble C at a syntactic level, such as C++, C#, Objective-C, Java, and Javascript. Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment `++`) or to reduce needless clutter (such as `;` or parentheses in `if` statements).

## Basic Syntax and Operators

 * [Replace `{}` brace syntax with Python-style indentation](https://forums.swift.org/t/brace-syntax/678/3): Surely a polarizing issue, but Swift will not change to use indentation for scoping instead of curly braces.

 * [Remove `;` semicolons](https://forums.swift.org/t/proposal-to-remove-semicolons/523/3): Semicolons within a line are an intentional expressivity feature.  Semicolons at the end of the line should be handled by a linter, not by the compiler.

 * [Replace logical operators (`&&`, `||`, `!`, etc.) with words like "and", "or", "not"](https://forums.swift.org/t/change-the-name-of-the-boolean-operators/30/2), and [allow non-punctuation operators](https://forums.swift.org/t/allowing-characters-for-use-as-custom-operators/952) and infix functions: The operator and identifier grammars are intentionally partitioned in Swift, which is a key part of how user-defined overloaded operators are supported.  Requiring the compiler to see the "operator" declaration to know how to parse a file would break the ability to be able to parse a Swift file without parsing all of its imports.  This has a major negative effect on tooling support. While not needing infix support, `not` would need operator or keyword status to omit the parentheses as `!` can, and `not somePredicate()` visually binds too loosely compared to `!somePredicate()`.

 * [Replace `?:` ternary operator](https://forums.swift.org/t/ternary-operator-suggestion/49/148): Definitely magical, but it serves a very important use-case for terse selection of different values.  Proposals for alternatives have been intensely discussed, but none have been "better enough" for it to make sense to diverge from the precedent established by the C family of languages.

## Strings, Characters, and Collection Types

This file has been truncated. show original

···

On Sat, Feb 27, 2016 at 1:17 PM Daniel Duan via swift-evolution < swift-evolution@swift.org> wrote:

Ross O'Brien via swift-evolution <swift-evolution@...> writes:

> Alternatives: replace 'default' with 'else'.

Unlike dropping the 'default' keyword (not commenting on that here), this
alternative idea adds very little value to warrant a change to the
language.
'default' is clear and well-understood as is.

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

Ross_O_Brien · February 27, 2016, 9:32pm

Xiaodi, thanks for pointing that out. That's an unfortunate oversight.

Following on from Brent's comments, then... the proposal as is will
probably be rejected as before. Since I seem to have acted too quickly in
submitting it, do you think I should close it, or leave it so it can be
edited? Would editing it be as simple as pointing its link to the
discussion on allowing dot-keywords (since, apart from Tim's suggestion of
Haskell's "otherwise", everything argued in this thread is in that one), or
is more substantial editing required?

--Ross

···

On Sat, Feb 27, 2016 at 9:06 PM, Jacob Bandes-Storch via swift-evolution < swift-evolution@swift.org> wrote:

Previous discussion:

[swift-evolution] Remove default case in switch-case

On Sat, Feb 27, 2016 at 12:52 PM, Rudolf Adamkovic via swift-evolution < > swift-evolution@swift.org> wrote:

+1 (as always) for replacing "default" with "case _".

It's consistent with other uses of "_", teaches about the concept of "_",
simplifies the language vocabulary, frees "default" to be used as a case
and it also looks better. :)

R+

Sent from my iPhone

> On 27 Feb 2016, at 15:31, Ross O'Brien via swift-evolution < >> swift-evolution@swift.org> wrote:
>
> Let's make this a topic of its own.
>
> As mentioned recently in the '[Idea] Allowing most keywords after "."'
thread, the 'default' keyword is only used as a keyword in switch
statements, where it's synonymous with 'case _:'.
> It's also the kind of word which appears commonly in enums.
>
> So, why do we need to keep it as a keyword?
>
> Disadvantages: there would be some breaking of code, but a migration
tool should have little difficulty replacing 'default:' with 'case _:' in
all cases.
>
> Alternatives: replace 'default' with 'else'.
> _______________________________________________
> 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

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

Brent_Royal-Gordon · February 27, 2016, 8:35pm

This idea (replacing default) has already been proposed previously and rejected. See: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

It has been proposed before, but the switch to lowercase for enum cases and option set values may change the calculus.

(Which is why I *don't* think this should have been spun off into its own thread—you've detached the proposal from its justification.)

···

--
Brent Royal-Gordon
Architechies