Simplify Enum case declarations - Eliminate the need of case prefix

Here is the current syntax for enum declaration. This requires each value of an enumeration to be prefixed with case keyword. But eliminating the need to prefix case will simplify the syntax.

I want the case keyword to be used for only one purpose, that matching expressions in a switch statement.

enum HttpMethod : String {
    case get = "GET"
    case post = "POST"
    case put = "PUT"
    case delete = "DELETE"
}

enum Result<Success, Failure> where Failure : Error {

   case success(Success)
   case failure(Failure)
}

New Syntax

enum HttpMethod : String {
    get = "GET"
    post = "POST"
    put = "PUT"
    delete = "DELETE"
}

enum Result<Success, Failure> where Failure : Error {

   success(Success)
   failure(Failure)

   var property: Int { return 1 }

   func getDescription() -> String {
     return "description" 
   } 
}

As you can see from the syntax, the new syntax is not hard to understand. All enums we declare will have the respective cases defined first and then the other properties/methods. This won't intorduce any confusion among developers.

2 Likes

I never felt the need to shorten enum declarations. They only appear at, well, the declaration site, and enum case names are seldom very long so it's not like you need the space. Also, typically you want a single case per line, so it's not a big problem. And when you do want to combine the cases on a single line, you can always leave out all but the last instance of case.

Besides, you always need to declare variables and functions with let/var and func, so it's a bit weird if cases break this pattern, especially in an enum where you have both funcs and cases.

11 Likes

You can already write:

enum E: String {
    case a = "a", b = "b"
}

E.b.rawValue // "b"

Eliminating the case keyword entirely seems overly terse, especially in a language that places a high value on explicitness.

If you want to improve something in this arena, open a radar for Xcode to format the multiline variant with proper (or any) indentation.

5 Likes

Lest we forget that we can define things other than case, like func, var.

6 Likes

I don’t see any benefits from making this change.

The litmus test for unnecessary syntax is simple: does the syntax remove any ambiguity that would otherwise be present? In this case (no pun intended), it does: you could instead use var, func, and other kinds of statements.

While you could make a lack of statement implicitly mean case, that would be both arbitrary and inconsistent with the rest of Swift.

I would not support this change (which seems a change solely for the sake of change). It removes clarity for little to no additional value.

1 Like

Agreed with others here. At best, not worth putting any time into. The existing syntax is too close to what's been proposed.

enum HttpMethod: String {
  case
    get = "GET",
    post = "POST",
    put = "PUT",
    delete = "DELETE"
}
enum Result<Success, Failure> where Failure : Error {
  case
    success(Success),
    failure(Failure)
}
2 Likes

I like this idea. I think it's particularly compelling for enums that have a great deal of cases. The original example only shows four cases. Where I think this could really shine is enums with a great deal of cases, especially for those that may or may not have an associated value.

enum Event {
    case event1
    case event2(String)
    case event3
    case event4(String, Int)
    case event5
    case event6(String, String, String)
    case event7
    case event8(Int)
    case event9(Event)
}

I do agree that simply omitting the case statement is overly terse. Drawing some inspiration from what @Jessy accomplished with some clever nesting, what about something like:

enum Event {
    cases {
        event1
        event2(String)
        event3
        event4(String, Int)
        event5
        event6(String, String, String)
        event7
        event8(Int)
        event9(Event)
    }
}

I don't understand that would be any better than

enum Event {
    case
        event1,
        event2(String),
        event3,
        event4(String, Int),
        event5,
        event6(String, String, String),
        event7,
        event8(Int),
        event9(Event)
}

Which is possible today.

8 Likes

Don't have to remember to do comma maintenance as the cases are edited.

The bar for syntax changes which offer no new functionality is way higher than dealing with trailing commas.

3 Likes

I actually kind of not completely agree with few opinions about not recommending this change.

For people that believe that Swift prefer complete explicitness, let me remind that Swift no longer requires return keyword in single line functions. I don't see any explicitness in removing the need to use the return keyword.

If we talk about explicitness
a. why functions that return void work very well without Void keyword added explicitly?
b. Why a function with a single line doesn't require a return keyword mentioned explicitly?

To answer to above questions, one can easily say it was made to simplify the syntax as removing them will not change the meaning of the statements. This pitch is also proposing a similar change. I don't see any reason to disagree with it.

Swift is meant to be simple and that means simplifying the syntax to do something using it. Removing the case keyword doesn't remove any explicitness IMO. C# and other languages also use a similar syntax.

1 Like

There are often various concerns which are at odds with each other.

The decision to allow return to be omitted was based on consistency. Closures already allowed omission, and other invokable blocks were brought in line.

I don't know the rationale for omitting -> Void for return types.

There is, however, no precedent for omitting a declaration keyword.

We should stick with "case a, b, c" Aside from "case" adding only four characters per enum, most of my enums contain not just the cases but also members and methods. I like being able to tell, at a glance, which is which.

3 Likes

There is no value for this. -1

1 Like
Terms of Service

Privacy Policy

Cookie Policy