You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think there's much point in supporting custom results. One intended benefit for this was to support things like returning io::Result directly - but having the user do into() on that isn't asking too much more in the end.
Also given Microsoft is developing com-rs, I'm fine giving up on the "Intercom needs to be able to call any COM API" requirement and instead aim for "Most COM APIs but with the best ergonomics possible" and I feel requiring ComResult for fallible methods will give more benefits:
We can remove #[infallible] and instead assume that any method that doesn't return ComResult should be considered #[infallible].
We might be able to target stable Rust. The error traits are one of the only ones that require specialization currently.
With stricter types, it should be easier to figure APIs for supporting custom error info when serializing into ComError.
The text was updated successfully, but these errors were encountered:
I don't think there's much point in supporting custom results. One intended benefit for this was to support things like returning
io::Result
directly - but having the user dointo()
on that isn't asking too much more in the end.Also given Microsoft is developing
com-rs
, I'm fine giving up on the "Intercom needs to be able to call any COM API" requirement and instead aim for "Most COM APIs but with the best ergonomics possible" and I feel requiringComResult
for fallible methods will give more benefits:#[infallible]
and instead assume that any method that doesn't returnComResult
should be considered#[infallible]
.The text was updated successfully, but these errors were encountered: