I think you're proving the author's point.

GreenDolphinSys 2 hours ago | parent | next [-]

They're saying that you don't always have to return Result<T, Box<dyn Error>>, you can implement the From<Error> trait on the type and use ? as usual.

In other words implementing that trait lets you set a return type like Result<T, CustomAppError> use ? on it.

▲

LoganDark 2 hours ago | parent [-]

I think they're saying the author's point is that it's more fiddly in Rust (even if there are strong, well-regarded fiddles to use)

▲

GreenDolphinSys an hour ago | parent | next [-]

I don't think errors are fiddly in rust. They're easy to compose.

▲

Graziano_M 2 hours ago | parent | prev [-]

Yes, and your other part about the crate.

> There's also Zig-style composable errors with yet another library.

▲

LoganDark 2 hours ago | parent [-]

Ah, it's behind a link!

While I'd push back against implying From<E2> is part of the crate, thiserror is an idiomatic approach these days, so I can understand the confusion. I can totally see how they could come to favor Zig if this behavior is "the default", as opposed to Rust where you'd usually see it done with "yet another library".

And so I see "the author's point" has another meaning now: that Zig-style errors are good :)

Edit: oh, after looking into Zig-style errors more, this is actually not how they work! They don't nest, they just exist in a global namespace, so they don't come with any location data themselves, but you can compose sets of them. Less powerful, but certainly more appealing to some :) I think out-parameters can be used as a side channel for error context.

	▲	Graziano_M 2 hours ago \| parent [-]
		Yeah I 1. wish they were properly composable and 2. think Rust would get less flak if these 'idiomatic' crates were just pulled into the standard library to avoid some of the dependency mayhem.

▲

tcfhgj 2 hours ago | parent | prev [-]

how so?

	▲	2 hours ago \| parent [-]
		[deleted]