Yes it does. Also, while I'd agree that there are important, fundamental things that are missing from the language, if someone identifies a natural addition that feels in line with the rest of the language with no downside and provides an implementation, you really need solid ground to oppose their proposal.
The protocol:
protocol DecodingError {
static var fileCorrupted: Self { get }
static func keyNotFound(_ key: String) -> Self
}
has very simple semantics: a fully qualified instance of a type conforming to DecodingError must have at least a fixed constructor called fileCorrupted, declared as a static member, and a constructor called keyNotFound(_:) declared as a static function, that takes a String. The enum:
enum JSONDecodingError {
case fileCorrupted
case keyNotFound(_ key: String)
}
fully respects the semantics, therefore it should be able to conform to that protocol as it this, from the purely syntactic point of view. Can't speak about the complexity of the "feature" (but this really seems something that it's missing and should've be already there in the first place) but its utility and fitness with the language seems rather obvious to me. Therefore, I support the proposal.
As a regular swift user following swift evolution out of curiosity i might miss the deeper qualities of these kinds of proposals but it really feels like there is a bunch of people in the forum who really love type system gymnastics for the sake of it. I don't get what the convincing use case / benefit of this would be.
A benefit would be consistency. It may not be obvious (ok, it isn't), but cases are constructors in disguise. This is really apparent when there are associated values:
enum MyEnum {
case myCase(String)
}
let x: (String) -> MyEnum = MyEnum.myCase
let value = x("hi") // .myCase("hi")
There's no particular reason to forbid myCase(String) from satisfying a protocol constraint.
I mean that these are indistinguishable at call site in every single aspect except one:
enum Foo {
case bar
case qux(Baz)
}
struct Foo {
static var bar: Self { /* ... */ }
static func qux(_: Baz) -> Self { /* ... */ }
}
Everywhere you can use one, you can use the other, with exactly the same syntax, and the same semantics. Except only the latter can be used to satisfy protocol requirements.
This pitch proposes to close this gap, thus making the language simpler, and more consistent with fewer exceptions, and therefor an easier mental model. It has less cognitive load, and aligns better with expectations. At least mine.
The important issue is not that it is hard to implement the conformance. The most significant issue was clearly demonstrated in the pitch:
You cannot have a case with a name that matches the protocol requirement, which may often be exactly what is desired. It should not be necessary to compromise the name of a case in order to provide the protocol conformance. This is the primary motivation IMO. The convenience of not having to write it manually is also nice of course, but that is not primary motivation.
This is not what we want and would not be a viable option. What we want is for the member already synthesized by the compiler to be eligible to fulfill protocol requirements.
I don’t view this as an alternative. It’s an orthogonal (but related) feature. The reason it isn’t an alternative is that it does not support conformance by non-enum types. The use cases I have for this feature are in places where pattern matching in generic code is not necessary so a case requirement would be unnecessarily restrictive.
As mentioned above, the generic code I have written where I wanted this feature has always been in contexts that do not need pattern matching. The pitch as it is written lifts the limitation I have bumped into many times.
It lets us design libraries which place factory requirements on user-defined types which will often be enums, without imposing boilerplate and compromise on the design of those user-defined enums. Both the boilerplate and the necessity to compromise the case name are a very unfortunate limitation for a library to place on user-defined types.
You don’t have to understand all of the type system nuances in order to benefit from libraries written by those who do. There is a lot happening in the design of SwiftUI that relies heavily on sophisticated type system features. Most users of SwiftUI do not know anything about this and do not need to know anything about this. But without those type system features, SwiftUI would not be possible or would have a compromised experience for users. SwiftUI has been extremely well received in part because the language has the type system features necessary to support its design well, not in spite of them.
If this is true, imho it would be a strong argument — but in this case, the implementation should clearly decrease the loc of the compiler, shouldn't it?
When I’m talking about simpler, it means that there are fewer concepts, and that the features are orthogonal and composable, with few exceptions. In order to have a uniform story across different parts of the language, you sometimes need to implement the same thing twice.
How the implementation of this specific feature fits the current architecture of the compiler source code, I cannot tell. Only that as a user, it fits the existing model and makes enum cases behave like exactly like static funcs, instead of almost exactly.
Big +1 to this proposal. It would clean up my code in a lot of places.
It seems to me that some of the confusion around “treating enum cases like static properties” is more a side effect of the fact that Swift enums are (and should continue to be) much more powerful than enums in many languages. When I first learned to code, enums were just simple lists of case labels that under the hood could often be thought of as integers when appropriate. Because of this, it was surprising to me the first time I started to work with associated values and Indirect enums. Now that I have had time to adjust my mental model for enums to simply be “a sum type” the way Swift enums work is much less surprising and incredibly useful. I’m not saying every coder needs to think “sum type” when they read enum, but if their intuition around the word “case” can change to “static constructor for a type that happens to enumerate all it’s possible values” then this pitch starts to seem less surprising than the existing lack of the capability does.
Benefits have become a bit clearer to me with the recent posts. It is no secret that "internal" features can hugely improve stuff downstream. But this proposal did not make those benefits as clear to me (as for instance the opaque return type one did via concrete use cases that were clearly understandable). Thanks to all who made it clearer.
Imho there is a really simple remedy against most kinds of doubters: Compelling examples.
I guess plain code is too trivial for those who desperately need this new feature ;-), but I ended up with this:
Summary
protocol DecodingError: Error {
static var fileCorrupted: Self { get }
static func keyNotFound(_ key: String) -> Self
}
class Reader<E: DecodingError> {
func read(key: String) -> Result<String, E> {
return Result.failure(E.keyNotFound(key))
}
}
enum DecodingErrorEnum: DecodingError {
case fileCorruptedCase
case keyNotFoundCase(String)
static var fileCorrupted: DecodingErrorEnum {
return .fileCorruptedCase
}
static func keyNotFound(_ key: String) -> DecodingErrorEnum {
return .keyNotFoundCase(key)
}
}
let r = Reader<DecodingErrorEnum>()
let result = r.read(key: "Test")
if case Result.failure(let error) = r.read(key: "Test") {
switch error {
case .fileCorruptedCase:
print("file corrupted")
case .keyNotFoundCase(let key):
print("Key \(key) missing")
}
}
Is this what people want to do with this pitch?
The conformance is hardly useful at the client side (func handleError(_ error: DecodingError), so "injecting" the enum into a context that creates an instance seems to be the only possibility.
I'm just not sure why I should want to create a protocol in the first place instead of simply using the enum...
Protocols can require specific instance methods and type methods to be implemented by conforming types. These methods are written as part of the protocol’s definition in exactly the same way as for normal instance and type methods, but without curly braces or a method body.
Variadic parameters are allowed, subject to the same rules as for normal methods
As with type property requirements, you always prefix type method requirements with the static keyword when they’re defined in a protocol. This is true even though type method requirements are prefixed with the class or static keyword when implemented by a class
Reads quite simple to me - but with this pitch, those explanations would become invalid, and I can hardly think of a change that does not introduce a special case or an exception specific for enums... so no, I don't think Swift would be more simple with this.
Well, that quoted text already has an
exception that class methods can be used to conform to a static func protocol requirement.
The mental model I have is that everything that acts like, and can be used as, a static func, can be used to satisfy a static func protocol requirement.
I was baffled when I first realized that this was the he case for everything, except enum constructors. This would close that gap.
I really like this! It would work great for things like this:
protocol Defaultable {
static var default: Self { get }
}
#if DEBUG
protocol TestInstanceable {
static var testInstance: Self { get }
}
#endif
enum MyEnum: Defaultable, TestInstanceable {
case default
case other
#if DEBUG
case testInstance
#endif
}
I think that's my only concern. It seems there's not currently a mechanism to do this, but it feels like an odd exception that the only static to Self witness to not work would be an empty function. I'm guessing that would be the main thing to cause user confusion. Has there been discussion of overloading an enum case with a function version similar to those with associated values?
let thing: () -> AnEnum = AnEnum.emptyCase
This already works with a static method:
enum Test {
case other
static func other() -> Test {return .other}
}
let otherThing: () -> Test = Test.other
It would probably need a separate proposal to make it always visible, but maybe it could be added only to enable the protocol witness?
Anyway it sounds like case emptyCase(Void = ()) would work, so maybe that's a good enough workaround for now. Also a good opportunity for someone to gain some SO reputation
Unfortunately that will not work, since the type would be (()) -> Self. I think we could relax the rules as part of “Properties with function type” feature mentioned in the manifesto.
enum Foo {
case bar(Void = ())
}
// This has type (Void) -> Foo / (()) -> Foo
// NOT Void -> Foo / () -> Foo
let f = Foo.bar
f() // error: Missing argument for parameter #1 in call
(I will clarify what I meant by the default argument point - what I was trying to say was that you cannot declare a case foo() today and doing case foo (Void = ()) is not the same as what you think it is).
Ah right, I'm guessing it would be possible to make this work with some extra internal changes but there are better options if going that route. I definitely agree a case should be declared like that, but I think there's a case to have an available overload.
I'm guessing it would work if the Default Arguments section of Protocol Witness Matching Mini-Manifesto were added? (Something I've personally bumped up against other places so am hopeful to see added).
I think the problem is that they have different types, so it wouldn’t be a match. Also, case foo(Void) doesn’t give you a .foo back but rather a .foo(()) back which is probably not what you want.
As I mentioned before, we could allow a case foo to be matched by a func foo() -> Self in the future. At the moment, the model is that payload-less cases behave like vars and payload cases like funcs. The manifesto mentions that we could allow them to “mismatch” (i.e allow a function req to be satisfied by a property with function type and vice versa) and I think that this should be bought up when that goes through the pitch phase, rather than introducing a special case right now.
Ah right. We have no way to represent an anonymous function with default arguments or the function-with-default-arugments form.
To clarify my understanding, with this proposal...
protocol Foo {
static var one: Self { get }
static func two(arg: Int) -> Self
static func seven() -> Self
}
enum FooEnum: Foo {
case one // Satisfies Foo.one via FooEnum.one
case two(arg: Int) // Satisfies `Foo.two` via `FooEnum.two` (Type: `(Int) -> FooEnum`)
case seven // Not a match because this doesn't have a `() -> FooEnum` representation
case seven(Void = ())
// Still not a match because the Type of `FooEnum.seven` is `Void -> FooEnum` not `() -> FooEnum`
}
The pitch is for making code easier for the user, not for the Swift compiler team. This isn’t adding a new dynamic in the model, but fixing a hole. From the user’s perspective, enumeration cases have the same interaction model as type properties and methods. So the fact that cases can’t match to protocol members is a bug. It’s a bug that several people here, including myself, have hit. (A related thread has a list of relevant bugs in the database.). It is not some theoretical flight of fancy.
