You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SR-2176 Add warning for ambiguous enum value assignment
Issue Description:
For example, if we have this enum:
enumFoo: String {
casevalidcasenone
}
And then we initialize an optional variable like this:
letfoo: Foo? = .none
We should get an ambiguity warning as it is not clear if we are talking about
Optional<T>.noneORFoo.none
Currently the only way to tell them apart is because of the syntax coloring, and at this moment the compiler is choosing Optional<T>.none over Foo.none, but I'm unable to tell at this time if this is defined behavior or not. If it is not defined behavior it might change in the future and break source compatibility.
The text was updated successfully, but these errors were encountered:
So, it looks like the behavior is close to what would be expected: if your enum doesn't have .none / some(_: T) reference then of course you don't want any kind of warning, but it'd be interesting to check for possible collisions that are not possible in other scenarios.
I think it'd be terrific some kind of alert if you're targeting an optional enum whom's valid cases counts with something named .none or .some (with or without arguments), so only in those cases you may prefer to be deterministic or just rename the enum case (that's what we did with @Julioacarrettoni)
Given than .none is a widely used enum case (not to describe optionals) our thinking process led us to understand that it could be a good addition 🙂
Additional Detail from JIRA
md5: 5a2feeb8a0ecad150f2c0b50fa47a998
duplicates:
Issue Description:
For example, if we have this enum:
And then we initialize an optional variable like this:
We should get an ambiguity warning as it is not clear if we are talking about
Currently the only way to tell them apart is because of the syntax coloring, and at this moment the compiler is choosing Optional<T>.none over Foo.none, but I'm unable to tell at this time if this is defined behavior or not. If it is not defined behavior it might change in the future and break source compatibility.
The text was updated successfully, but these errors were encountered: