Since SE-0352, the language can implicitly open existentials, and this has tremendously improved the support for generics.
Implicitly Unwrapped Optionals (IUOs) were forgotten, though. The following code does not compile, and this is a bad surprise for developers:
protocol P { }
func use(_ p: some P) { }
struct S {
var iuo: P!
var p: P
init() { fatalError("irrelevant") }
func test() {
use(p) // OK
use(iuo) // ❌ Type 'any P' cannot conform to 'P'
}
}
This bad surprise can happen in the interaction between a library and its client code:
The library declares a generic public API. SE-0352 (supposedly) guarantees a nice integration with user code that uses existentials.
The library users declares a IUO existential property. We all know that IUOs are an important language tool that allows, for example, two-phases initialization.
In such a case, the library user complains to the library author about the compiler error discussed above. The library author investigates, and eventually replies that the real issue lies with the compiler (this issue). Everybody has lost time and energy. In the end, the library user needs to workaround the compiler issue and uglify their code with extra properties or local variables:
// workaround
let p: P = iuo
use(p)
Proposed solution
Please complete the support for SE-0352, and make sure implicitly unwrapped optionals are handled as expected by their users.
I recently reported a distinct but similar issue: #72727. It looks like the importance of implicitly unwrapped optionals is under-evaluated. Please do not forget them.
Motivation
Since SE-0352, the language can implicitly open existentials, and this has tremendously improved the support for generics.
Implicitly Unwrapped Optionals (IUOs) were forgotten, though. The following code does not compile, and this is a bad surprise for developers:
This bad surprise can happen in the interaction between a library and its client code:
In such a case, the library user complains to the library author about the compiler error discussed above. The library author investigates, and eventually replies that the real issue lies with the compiler (this issue). Everybody has lost time and energy. In the end, the library user needs to workaround the compiler issue and uglify their code with extra properties or local variables:
Proposed solution
Please complete the support for SE-0352, and make sure implicitly unwrapped optionals are handled as expected by their users.
I recently reported a distinct but similar issue: #72727. It looks like the importance of implicitly unwrapped optionals is under-evaluated. Please do not forget them.
Alternatives considered
No response
Additional information
No response