[SR-10705] Enum Type Inference produces unexpected result with optional

[swift-ci]

Previous ID	SR-10705
Radar	None
Original Reporter	ConfusedVorlon (JIRA User)
Type	Bug
Status	Resolved
Resolution	Duplicate

Environment

Xcode Version 10.2.1 (10E1001)

Swift 5.0

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	None
Priority	Medium

md5: e393628d2dd2766b05c692488813f144

duplicates:

• SR-2176 Add warning for ambiguous enum value assignment

Issue Description:

var s1:UITableViewCell.SelectionStyle?{{ = .none}}

expected:

s1 == UITableViewCell.SelectionStyle.none

actual:

s1 == Optional.none == nil

This just caught me out in a project, and it seems like confusing behaviour. I understand that it will generate a warning in swift 5.1

quoting the Swift guide:

The type of directionToHead is inferred when it's initialized with one of the possible values of CompassPoint. Once directionToHead is declared as a CompassPoint, you can set it to a different CompassPoint value using a shorter dot syntax:

wheras perhaps it should have a more complicated

... you can set it to a different CompassPoint value using a shorter dot syntax - except watch out for variables that are optional, and where the case is called .none, because that will clash with the Optional (which is actually implemented as an enum) and select Optional.none from the outer type

my feeling is that this is the kind of 'gotcha' which languages should avoid. If you have to have a deep understanding of how the language is implemented to understand a special case when assigning a variable - then that is suboptimal

possible ideas for fixes:

1) change the precedence

when assigning to

var s1:UITableViewCell.SelectionStyle?

it feels to me that s1 is 'more strongly' identified UITableViewCell.SelectionStyle rather than Optional.

this may have broader unpleasant consequences though

2) change the case name within Optional so that it clashes less often

perhaps Optional.none -> Optional.nil would seem nice (although nil is not currently allowed as a case name)

otherwise Optional.null, Optional.nothing, Optional.empty ???

[swift-ci]

Comment by Rob Jonson (JIRA)

just a thought as to intent. I can't imagine many developers who wanted to achieve

s1 = nil

who would write that as

s1 = .none

or to flip it; If you're writing .none, you almost certainly don't mean nil

[swift-ci]

Comment by Rob Jonson (JIRA)

another possible fix; Make .none a protected word which only Optional is allowed to use as an enum case (and rename it across the frameworks)

[theblixguy]

The only time I have seen `.none` being explicitly used (instead of `nil`) is when looking at some extensions on Optional in the stdlib. I don't think anyone really uses it explicitly, so it might not be a source-breaking change to look through the optional when using the dot syntax. We can then tweak any code in stdlib that assigns `.none` explicitly and assign `nil` instead.

enum Foo { case none }
enum Bar { case notNone }

let foo1: Foo? = .none // Foo.none
let foo2: Foo? = Optional.none // nil
let foo3: Foo = .none // Foo.none

let bar1: Bar? = .none // nil
let bar2: Bar? = Optional.none // nil

What do you think @belkadan @slavapestov?

[theblixguy]

> another possible fix; Make .none a protected word which only Optional is allowed to use as an enum case (and rename it across the frameworks)

That will definitely be a source breaking change and would involve a lot more work - I'd prefer we don't do this!

[belkadan]

There's going to be a warning for this in Swift 5.1. I think that's probably the right place to stop.