[SR-14478] Optional<T>.none is accepted, but nil is not

[swift-ci]

Previous ID	SR-14478
Radar	rdar://problem/76598223
Original Reporter	ken (JIRA User)
Type	Improvement

Additional Detail from JIRA

Votes	0
Component/s
Labels	Improvement
Assignee	None
Priority	Medium

md5: 559996b58a5c9717778c0de4a68d738f

Issue Description:

There are some situations I've found where nil doesn't seem to be considered a valid Optional, but spelling out Optional<T>.none works fine. Extending Optional seems to confuse the compiler. For example:

$ xcrun swift
Welcome to Apple Swift version 5.3 (swiftlang-1200.0.29.2 clang-1200.0.30.1).
Type :help for assistance.
  1> protocol HotDogOrNot { }
  2> protocol HotDog: HotDogOrNot { }
  3> extension Optional: HotDogOrNot where Wrapped == HotDog { }
  4> func f(_ x: HotDogOrNot) { }
  5> f(nil)
error: repl.swift:5:3: error: 'nil' is not compatible with expected argument type 'HotDogOrNot'
f(nil)
  ^


  5> f(Optional<HotDog>.none)
  6> nil is HotDogOrNot
error: repl.swift:6:5: error: type of expression is ambiguous without more context
nil is HotDogOrNot
~~~~^~~~~~~~~~~~~~


  6> Optional<HotDog>.none is HotDogOrNot
$R0: Bool = true
  7> Optional<HotDog>.none == nil
$R1: Bool = true

I really have no intuition for whether this would be easy or hard to implement. From the user's point of view, it would be nice if Optional<T>.none were always able to be replaced by nil in source code.

Maybe part of #56764.

[typesanitizer]

@swift-ci create

[xedin]

ken (JIRA User) nil literal requires a contextual type, nil is HotDogOrNot expression is indeed "ambiguous" in a sense that it's impossible to determine what nil is but compiler should produce a better diagnostic, something like 'nil' requires a contextual type.

[swift-ci]

Comment by Ken Harris (JIRA)

I'm not sure I understand. When nil is passed to a func that takes a HotDogOrNot, what else could it be, besides Optional<HotDog>.none?

I suppose if someone else came along later and added:

extension Optional: HotDogOrNot where Wrapped == Durian { }

then this would retroactively create ambiguity in my previous statement, but there's already a million cases where adding new code can introduce ambiguity in existing code.

[xedin]

The compiler doesn't know anything about nil besides it's some type that is supposed to conform to ExpressibleByNilLiteral, which means it can't be passed to a HotDogOrNot parameter because value of existential type of protocol HotDogOrNot wouldn't conform to ExpressibleByNilLiteral. There is no association between nil and declaration extension Optional: HotDogOrNot where Wrapped == HotDog { } so compiler can't infer anything for nil from context like that or nil is HotDogOrNot.

[LucianoPAlmeida]

Hey @xedin =]

You mentioned diagnostics, on a near main branch it actually already produces that

error: 'nil' is not compatible with expected argument type 'HotDogOrNot'
f(nil)
  ^
error: 'nil' requires a contextual type
nil is HotDogOrNot
^
warning: 'is' test is always true
nil is HotDogOrNot
    ^

Actually I think the warning 'is' test is always true is wrong here. I can try take a look on that

[xedin]

@jreference might be a good bug for you to take a look at as well.

[AnthonyLatsis]

Is there a reason we never got to defaulting nil to Optional?