DarkSharpness commented on PR #399:
URL: https://github.com/apache/tvm-ffi/pull/399#issuecomment-3807017802
> Here is the API review
>
> ```
> | API | Category | Notes
|
>
|--------------------|----------|--------------------------------------------------------------------|
> | is_ok() | C0 | Follows std::expected::has_value()
semantics |
> | is_err() | C1 | Rust-style naming; equivalent to
!has_value() |
> | has_value() | C0 | Alias for is_ok(), follows C++ standard
|
> | value() | C0 | Follows std::expected::value()
|
> | value() && | C1 | Move-qualified overload for efficiency
(not in C++23 standard) |
> | error() | C0 | Follows std::expected::error()
|
> | error() && | C1 | Move-qualified overload for efficiency
|
> | value_or(default) | C0 | Follows std::expected::value_or()
|
> | ExpectedOk(value) | C1 | Rust-style helper; C++ standard has no
equivalent factory function |
> | ExpectedErr(error) | C1 | Rust-style helper; C++ standard has no
equivalent factory function |
> ```
>
> Rationale for C1 APIs:
>
> * Move-qualified overloads (&&): Added for performance when the Expected
is a temporary, avoiding unnecessary copies of large objects.
> * ExpectedOk() / ExpectedErr(): Rust-style factory functions for cleaner
syntax with type deduction. C++23 std::expected relies on constructors instead.
> * is_err(): Rust naming convention; provides symmetry with is_ok().
>
> APIs not implemented (compared to C++23 std::expected):
>
> * operator bool(): can use has_value() or is_ok() instead
> * operator*() / operator->(): unchecked access, omitted for safety
> * Monadic operations (and_then, transform, or_else, transform_error): may
add in future if needed
Thanks for the detailed API review.
One small difference worth calling out for `ExpectedOk` / `ExpectedErr` is a
C++-specific type deduction behavior compared to Rust. In Rust, generic
parameters can be inferred from the return type, while in C++ template argument
deduction only considers function arguments, not the return type. This means
that with factory-style helpers like `ExpectedOk`, the deduced type may
sometimes differ from the desired return type. For example:
```C++
template <typename T>
Expect <T> ExpectOk(T value);
Expect<long> function(int x) {
return ExpectOk(x); // <- in many cases, we want [T = long], which deduced
from return type.
// but in this case T will deduced as int, which may
lead to compile error.
}
```
In such cases, C++ cannot deduce `T = long` from the return type, which may
lead to a compilation error.
I'm not sure whether this will cause some inconvenience in real usage, but
the current design is reasonable for simplicity.
In XGrammar we implement something like `PartialExpected`, which can be
implicitly converted to any `Expected<T>` and solves the return type inference
problem. However, this actually introduces much complexity
https://github.com/mlc-ai/xgrammar/blob/aa44ded202fdaa2cb55f48deb31d17c9822a8a1f/cpp/support/utils.h#L130-L212
--
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]
