Date: Thu, 07 Dec 2023 07:52:55 -0800
On Thursday, 7 December 2023 07:29:14 PST Edward Catmur via Std-Proposals
wrote:
> We're not talking about U -> optional<Z> -> optional<T> though, we're
> talking about U -> optional<T> directly. Intuitively it seems that that
> should be preferred over U -> T -> optional<T>.
Sure, but does it matter?
If type U can be converted to T, then why shouldn't it be converted to T? This
type is declaring that it can produce a valid T.
You may argue instead that U will throw on conversion to T in the same
conditions that it would have returned a nullopt. That is, the code as it is
will compile and run for most conditions of the conversion, but will
unexpectedly throw in production when the conditions become adverse. That
would be a surprise factor because the developer may assumed they had handled
the throwing condition by providing this optional<T> conversion, but didn't
check by stepping through in the debugger that it's the overload that got
called.
It wouldn't be the first time that the wrong overload got called that does
something subtly different than what appears to be intended.
I'd welcome fewer surprises.
wrote:
> We're not talking about U -> optional<Z> -> optional<T> though, we're
> talking about U -> optional<T> directly. Intuitively it seems that that
> should be preferred over U -> T -> optional<T>.
Sure, but does it matter?
If type U can be converted to T, then why shouldn't it be converted to T? This
type is declaring that it can produce a valid T.
You may argue instead that U will throw on conversion to T in the same
conditions that it would have returned a nullopt. That is, the code as it is
will compile and run for most conditions of the conversion, but will
unexpectedly throw in production when the conditions become adverse. That
would be a surprise factor because the developer may assumed they had handled
the throwing condition by providing this optional<T> conversion, but didn't
check by stepping through in the debugger that it's the overload that got
called.
It wouldn't be the first time that the wrong overload got called that does
something subtly different than what appears to be intended.
I'd welcome fewer surprises.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-12-07 15:52:57