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

[swift-ci]

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]

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]

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

[xedin]

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

[swift-ci]

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]

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

[swift-ci]

Comment by Andyy Hope (JIRA)

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

[swift-ci]

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]

I've created a PR for review: #21621

[theblixguy]

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

[kavon]

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

[kavon]

Thank you for fixing this!