Details
-
Type:
Improvement
-
Status: Resolved
-
Priority:
Medium
-
Resolution: Done
-
Component/s: Compiler
-
Labels:
-
Radar URL:
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/
Attachments
Issue Links
- is duplicated by
-
SR-6044 We need an ambiguity warning for assigning .none to an optional enum where .none is a valid case.
-
- Resolved
-
-
SR-8283 Enum cases named "none" can cause ambiguity with Optional's "none"
-
- Resolved
-
-
SR-8451 Swift's optional lifting/promotion is overzealous
-
- Resolved
-
-
SR-10659 Append key problem on Dictionary with enum on specific scenario
-
- Resolved
-
-
SR-10705 Enum Type Inference produces unexpected result with optional
-
- Resolved
-
-
SR-3711 Make .member lookups in Optional<T> context ambiguous if member can be found in both Optional and T
-
- Closed
-
-
SR-8515 Compiler should show error for ambiguous enum cases with implicit casting
-
- Closed
-
- relates to
-
SR-3711 Make .member lookups in Optional<T> context ambiguous if member can be found in both Optional and T
-
- Closed
-