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

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

Comments

@Julioacarrettoni
Copy link
Mannequin

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
Component/s
Labels Improvement
Assignee None
Priority Medium

md5: 5a2feeb8a0ecad150f2c0b50fa47a998

duplicates:

  • 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.

@gonzalolarralde
Copy link
Contributor

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 🙂

Thanks!

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

let a: Test1? = .none        // Optional<Test1>.none
let b: Test1? = .foo         // Optional<Test1>.some(Test1.foo)
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
Projects
None yet
Development

No branches or pull requests

1 participant