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.

Sign up for GitHub

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

Jump to bottom

[SR-2176] Add warning for ambiguous enum value assignment #44784

Closed
swift-ci opened this issue Jul 26, 2016 · 11 comments
Closed

[SR-2176] Add warning for ambiguous enum value assignment #44784

swift-ci opened this issue Jul 26, 2016 · 11 comments
Assignees
@theblixguy
Labels
compiler The Swift compiler in itself good first issue Good for newcomers improvement

Comments

@swift-ci
Copy link
Collaborator

Previous ID SR-2176
Radar rdar://problem/26126801
Original Reporter kelan (JIRA User)
Type Improvement
Status Closed
Resolution Done
Environment

Xcode v8.0 beta 3 (8S174q)
Apple Swift version 3.0 (swiftlang-800.0.34.6 clang-800.0.33)
Target: x86_64-apple-macosx10.9

AND

Xcode v7.3.1 (7D1014)
Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.31)
Target: x86_64-apple-macosx10.9

Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Improvement, StarterBug
Assignee @theblixguy
Priority Medium

md5: 1e3b35e57d95ed4fe6d3877bd98474f4

is duplicated by:

  • SR-6044 We need an ambiguity warning for assigning .none to an optional enum where .none is a valid case.
  • SR-8283 Enum cases named "none" can cause ambiguity with Optional's "none"
  • SR-8451 Swift's optional lifting/promotion is overzealous
  • SR-10659 Append key problem on Dictionary with enum on specific scenario
  • SR-10705 Enum Type Inference produces unexpected result with optional
  • SR-3711 Make .member lookups in Optional context ambiguous if member can be found in both Optional and T
  • SR-8515 Compiler should show error for ambiguous enum cases with implicit casting

relates to:

  • SR-3711 Make .member lookups in Optional context ambiguous if member can be found in both Optional and T

Issue Description:

I've been caught off-guard by the value that's chosen by the compiler when inferring the type to assign to an enum value. This can be especially surprising because nil is shorthand for Optional.none.

For example, if I have this enum:

enum Coverage {
    case all      ///< everything is covered
    case partial  ///< only partially covered
    case none     ///< nothing is covered
}

let myCoverageA: Coverage? = .all
let myCoverageB: Coverage? = .none

Because myCoverageA gets a value of .some(.all), you might expect the value of myCoverageB to be .some(.none), but in fact it is .none.

I think this would also come up in a double-Optional. For example:

let str: String?? = nil
// is it `.none` or `.some(.none)`?

Expect

I think it would be nice to have a compiler warning in ambiguous cases like this.

Notes

I wrote up a slightly more detailed example of this here: http://kelan.io/2016/type-inferior-ence/
@belkadan
Copy link
Contributor

I'm pretty sure this can only happen with Optional, because we don't look through any other types in dot-shorthand syntax, but it still seems like a good idea to me.

@belkadan
Copy link
Contributor

belkadan commented Oct 3, 2017

Hey, @xedin, think this is simple enough for a starter bug? It's "just" post-processing of a type-checked expression, right?

@xedin
Copy link
Member

xedin commented Oct 3, 2017

I think so, I can help out if anybody wants to take it too.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 4, 2017

Comment by Kelan Champagne (JIRA)

I'd love to be able to take this., especially because I reported it. But, it would be my very first Swift contribution, so I'd have a bit of a learning curve to climb. Also, coincidentally, I just started at Apple (yesterday!), so I think there are some forms I need to submit, etc before I can actually post any PRs.

But, I'm really interested in learning how to do this, so if it's not urgent, I'd like to give it a shot.

@xedin
Copy link
Member

xedin commented Oct 4, 2017

kelan (JIRA User) Sure, take your time! If you need any help please do let me know.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jan 9, 2018

Comment by Andyy Hope (JIRA)

Hey kelan (JIRA User) - You still doing this? Sounds interesting 🙂

@swift-ci
Copy link
Collaborator Author

swift-ci commented Jan 9, 2018

Comment by Kelan Champagne (JIRA)

andyyhope (JIRA User)- I haven't actually started on anything for this yet. I am still interested, but there is some process I have to get through first. So, if you're excited about it – go ahead.

If you're looking for StarterBugs, another one I had on my list to look at is SR-5982. Although that one looks a little more involved (but probably also more interesting).

@theblixguy
Copy link
Collaborator

I've created a PR for review: #21621

@theblixguy
Copy link
Collaborator

Fixed on master. I'll cherry pick this to the 5.0 branch.

@kavon
Copy link
Contributor

kavon commented Jan 6, 2022

This is fixed as of at least Swift 5.5, so I'm closing this.

@kavon
Copy link
Contributor

kavon commented Jan 6, 2022

Thank you for fixing this!

@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
Assignees

@theblixguy theblixguy

Labels
compiler The Swift compiler in itself good first issue Good for newcomers improvement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@xedin @kavon @belkadan @theblixguy @swift-ci