tqchen commented on PR #399:
URL: https://github.com/apache/tvm-ffi/pull/399#issuecomment-3811460688
Thinking a bit more about partial deduction, it might be useful to think
about the usages, the main thing to consider is consistency with
`std::optional`, the following code is generally a common pattern:
```c++
std::optional<long> func_optional(bool valid, int x) {
if (value) return x;
return std::nullopt;
}
```
We can find that return value conversion from x to `std::optional<long>` is
automated by the return type.
So what @DarkSharpness mentioned is that it is desirable to have similar
syntax. In which case ExpectedOk and ExpectedErr follows the similar rationale
of targetted usage.
```c++
Expected<long> func_optional_rvalue_deduce(bool valid, int x) {
if (value) return ExpectedOk(x);
return ExpectedErr(Error("ValueError", "xx"));
}
```
In the current impl, we need to write it as
```c++
Expected<long> func_optional_param_deduce(bool valid, int x) {
if (value) return Expected<long>(x);
return Expected<long>(Error("ValueError", "xx"));
}
```
The main question we want to ask is the common usage scenarios the sugar
ExpectedOk/ExpectedErr, e.g. are they mostly used in the case similar to
`func_optional` where we want to simplify by deducing from return values, if
so, then I think the deferred deduction is wortwhile, alternatively we should
left out the ExpectedOk/ExpectedErr sugar since for most common case we expect
people to explicitly write `Expected<T>`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
