If we support operators expressing underlying functions, is it possible to implement an operator that relays to a function with the following signature: (lhs: T, rhs: U, file: StaticString = #file, line: UInt = #line) -> V
, and then provide an operator association attribute @operator(valid_operator, fixity: infix)
?
We already introduced use cases from code from a variety of developers into the proposal. The operator's use in the wild, to be clear, drove this proposal, in a variety of domains from Cocoa to iOS. Upthread, uses with C APIs were discussed by Jacob Williams. I don't believe the proposal is lacking a breadth of use-cases. Any developer who may experience an unexpected failure related to unwrapping an optional, who wishes to emit diagnostic information about that unexpected failure, is a candidate for this solution regardless of whether iOS, server side, system tool, C interop, etc.
Focusing on the fixit, which I know you specifically asked to be removed, may be pulling this discussion off-course as with any text relating to pedagogy, even though learning and naive users are major drivers of the problem domain.
That the solution has not been generalized to try!
or as!
does not mean this issue is not an important one that should be addressed. I believe this loss of focus is due to a fundamental issue of language expressibility and diagnostics. I would like to see operator-nonoperator coupling discussed further. I'd like to see fixits discussed further. I would like to see better diagnostics for try!
and as!
. But for now, I'd like to see a commitment to a solution to this particular problem: the unexpected deployment catastrophe encountered when unwrapping an optional that is otherwise guaranteed to hold a value.