Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-6044] We need an ambiguity warning for assigning .none to an optional enum where .none is a valid case. #48601

Julioacarrettoni mannequin opened this issue Oct 2, 2017 · 1 comment


Copy link

Julioacarrettoni mannequin commented Oct 2, 2017

Previous ID SR-6044
Radar None
Original Reporter @Julioacarrettoni
Type Improvement
Status Resolved
Resolution Duplicate
Additional Detail from JIRA
Votes 1
Labels Improvement
Assignee None
Priority Medium

md5: 5a2feeb8a0ecad150f2c0b50fa47a998


  • SR-2176 Add warning for ambiguous enum value assignment

Issue Description:

For example, if we have this enum:

enum Foo: String {
    case valid
    case none

And then we initialize an optional variable like this:

let foo: Foo? = .none

We should get an ambiguity warning as it is not clear if we are talking about

Optional<T>.none OR Foo.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.

Copy link

gonzalolarralde commented Oct 2, 2017

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 🙂


enum Test1 {
    case none
    case foo
    case some(_: Any)

let a: Test1? = .none        // Optional<Test1>.none
let b: Test1? = .foo         // Optional<Test1>.some(
let c: Test1? = .some(.none) // Optional<Test1>.some(Test1.none)
let d: Test1? = .some("foo") // Optional<Test1>.some(Test1.some(String))

enum Test2 {
    case none
    case foo
    case some

let z: Test2? = .some        // Optional<Test2>.some(Test1.some)
let y: Test2? = .some(.some) // Optional<Test2>.some(Test1.some)

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant