[SR-10705] Enum Type Inference produces unexpected result with optional #53102
Comments
|
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 |
|
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) |
|
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 // nilWhat do you think @belkadan @slavapestov? |
|
> 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! |
|
There's going to be a warning for this in Swift 5.1. I think that's probably the right place to stop. |
Environment
Xcode Version 10.2.1 (10E1001)
Swift 5.0
Additional Detail from JIRA
md5: e393628d2dd2766b05c692488813f144
duplicates:
Issue Description:
var s1:UITableViewCell.SelectionStyle?{{ = .none}}expected:
s1 == UITableViewCell.SelectionStyle.noneactual:
s1 == Optional.none == nilThis 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:
wheras perhaps it should have a more complicated
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 ???
The text was updated successfully, but these errors were encountered: