Stream: project-error-handling

Topic: generic member access visitor


view this post on Zulip bstrie (May 24 2021 at 23:11):

I'll admit that the generic member access RFC sort of makes my eyes glaze over, but this blog post about a crate for extracting data from trait objects struck me as similar in intent, so maybe it will be of interest: https://tokio.rs/blog/2021-05-valuable

view this post on Zulip Jane Lusby (May 24 2021 at 23:14):

for sure, nika and I already talked with them a bit about it in their discord a few months back when they first started working on Valuable

view this post on Zulip Jane Lusby (May 24 2021 at 23:20):

Looking at it though, I don't really see how it helps solve any of the problems for generic member access

view this post on Zulip Jane Lusby (May 24 2021 at 23:20):

we don't need to visit the members arbitrary dyn Errors in ways that are motivated by the content of those errors

view this post on Zulip Jane Lusby (May 24 2021 at 23:21):

the reason I wanted generic member access was to get SpanTrace out of dyn Errors

view this post on Zulip Jane Lusby (May 24 2021 at 23:21):

or ExitCode

view this post on Zulip Jane Lusby (May 24 2021 at 23:21):

or http::StatusCode

view this post on Zulip Jane Lusby (May 24 2021 at 23:21):

or stuff like that

view this post on Zulip Jane Lusby (May 24 2021 at 23:22):

basically a generic way to spell out the various fn backtrace(&self) -> Option<&Backtrace> like functions that you could imagine for any specific application

view this post on Zulip Jane Lusby (May 24 2021 at 23:23):

with a valuable like API we'd have go ignore all of the field names, and we'd be restricted to types that fit within the Valuable API, which is centered around an enum small set of variants, where as Generic member access relies on type erasure


Last updated: Jan 26 2022 at 14:02 UTC