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.
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.
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 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 @anon9791410 accomplished with some clever nesting, what about something like:
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.
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.