[SR-2176] Add warning for ambiguous enum value assignment Created: 26 Jul 2016  Updated: 9 Jan 2018

Status: Open
Project: Swift
Component/s: Compiler

Type: Improvement Priority: Medium
Reporter: Kelan Champagne Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: StarterBug
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


Issue Links:
Duplicate
is duplicated by SR-6044 We need an ambiguity warning for assi... Resolved
is duplicated by SR-3711 Make .member lookups in Optional<T> c... Closed
Relates
relates to SR-3711 Make .member lookups in Optional<T> c... Closed
Radar URL: rdar://problem/26126801

 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/



 Comments   
Comment by Jordan Rose [ 26 Jul 2016 ]

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.

Comment by Jordan Rose [ 3 Oct 2017 ]

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

Comment by Pavel Yaskevich [ 3 Oct 2017 ]

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

Comment by Kelan Champagne [ 4 Oct 2017 ]

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.

Comment by Pavel Yaskevich [ 4 Oct 2017 ]

Kelan Champagne Sure, take your time! If you need any help please do let me know.

Comment by Andyy Hope [ 8 Jan 2018 ]

Hey Kelan Champagne - You still doing this? Sounds interesting

 

Comment by Kelan Champagne [ 9 Jan 2018 ]

Andyy Hope- 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).

Generated at Sun Apr 22 11:22:56 CDT 2018 using JIRA 7.3.4#73015-sha1:a262b3457b3605f12635df4b0a0c3dc71d631a1e.