How hard is it to write the conformance yourself?
In my opinion, our goal is not (or at least should not be) to add as many changes as possible - I’m pretty sure we disarded many pitches with a better motivation in the past.
2 Likes
I'm not sure if you're still editing your post or if its the final state of it. Therefore I'm going to answer only to the current state with a counter question.
Can you show us a way to write the conformance for this particular 'simplified' case?
protocol P {
static var foo: Self { get }
}
enum E: P {
case foo // this is a required case for example
// error: compiler is not happy with the conformance
}
How would you now solve the issue while not changing the name of the enum case? I would love to understand what you refer as 'sound code' for such a use case. 
5 Likes
Your problem here is that compiler would give an error "Invalid redeclaration of 'foo'". If you want enum case can have same name with a static var (which I'm not sure if it could be solved), then bring up another ticket. Or as you said, we could just change the name of the enum case. So simple.
By the way, Objective-C has simlilar name clash issues (which could result in bug in runtime). Swift in this case reports an error in compile time, which I think is much safer.
With all my respect to you and your endurance in this discussion, I don't understand this. The proposal is exactly the solution for that problem. The conformance can be safely allowed, and the restriction that we have today can be lifted. It does not mean that things the compiler does not allow us today, should never happen. Or what other ticket do you want me/us to bring up?
4 Likes
protocol P {
static var foo: Self { get }
}
enum E: P {
case foo // this is a required case for example
static var foo: E {
return E.foo
}
}
You want to allow this to be compiled, then bring up another ticket.
This proposal looks great!
Enum cases without payload should definitely match static var requirements, and those with payloads should match function requirements. That’s just common sense.
We can start with this simple model, and then if the situation of needing to match an enum case to a zero-argument function arises frequently, we can address it in a follow-up proposal if necessary.
4 Likes
Why should one wish to allow redeclaration of identifiers in such a narrow case, which is far more difficult to teach, IMO, and fraught with difficulties (how do you distinguish between them? How is that return value not infinitely recursive?)
The solution proposed here is also narrow in scope, but it's a natural progression from features the language already has. We don't have to introduce an exception for a very clear rule to make it work.
3 Likes
I am not suggesting doing this, just stating it is one option.
I would prefer change the case name, then manually write the conformance.
I agree. Change for the sake of change is not helpful, and is thus undesirable in a language aiming for both source and binary stability. I think, though, that there's a difference between evaluating whether the problem is worth solving and whether a specific solution is the best solution for the problem.
You seem to be questioning the former, while @Zhu_Shengqi is questioning the latter. Your question requires the author of the pitch, or its supporters, to convince you. The latter requires the questioner to articulate why the proposed solution is subpar, and hopefully, offer a better solution.
2 Likes
I am not questioning the latter. I don't event think the problem is worth solving. Changing either the protocol static var names or the enum case names solves the issue. That's it.
I'd like to pitch in with my support. This will give enums a simple way to have protocol-based "inheritance", by having a subset of common cases defined by the protocol. Off the top of my head, I can think of a few places where I would take advantage of this.
More or less the same as Enum cases as protocol witnesses - #5 by davdroman.
3 Likes
Perhaps this is a language issue? You are offering a solution that requires one to write less-clear code, while saying there's nothing that needs solving. This need to contort code is exactly what we're trying to minimize. Naming is one of the most difficult aspects of programming. This pitch aims to make it slightly easier, whilst having no affect on enums that are not conforming to protocols with static requirements. You haven't provided any actual or theoretical downsides.
1 Like
First, I won't write or recommend writing the code that raise this pitch. Second, changing names (like adding prefixes) doesn't mean "less-clear code". Before swift people are writing Objectivc-C all these years, why suddenly all these syntactic sugar stuff are proposed? Clear code has nothing to do with syntactic sugar.
Clear code is almost always the impetus behind syntactic sugar. Brevity aids in comprehension.
This discussion is obviously going nowhere, so I won't respond to follow-ups. If this pitch makes it to the proposal phase, we can discuss the technical merits.
Okay I think the discussion reached some heated level. It's fair to say that this isn't going anywhere right now as there were no evidence presented that the current proposal will cause any actual harm. We should all back off and enjoy the rest of the day. Everyone feel free to be invited to post your thoughts during the review period. 
3 Likes
An alternative design could be to allow case in protocols:
protocol DecodingError {
case fileCorrupted
case keyNotFound(_ key: String)
}
enum JSONDecodingError: DecodingError {
case fileCorrupted
case keyNotFound(_ key: String)
}
This would force the protocol to be implemented as an enum, but it could allow pattern matching on the associated values:
let error: DecodingError = ...
switch error {
case fileCorrupted: ...
case keyNotFound(let key): ...
@unknown default: ...
}
Of course, if we allow pattern matching it also means we can't satisfy such a protocol using a struct with static members, as you can't pattern-match fields in a struct.
I think the proposal is a bit unclear about the goals. Do we want a protocol capable of being implemented with both struct and enum types? Or do we simply want to have a protocol for grouping enum types with a common list of cases? Which one is more desirable?
7 Likes
I can't imagine a practical scenario for the former, but I know I would use the latter.
That said, unless there are clear downsides, I prefer the solution that allows for either, even if we then lose pattern matching on the protocol.
There has been past discussion on it, basically around adding the ability to restrict a protocol to just an enum (: enum) (see this thread for example).
1 Like
Although the effect is to restrict it to enum, that's not the really the goal. If we later add better pattern matching capabilities for struct and class, those types would be able to conform too.