This is equivocation between the person writing the catch block and the person reading the catch function’s signature, inverted roles 1/2
-
-
Replying to @withoutboats @ManishEarth and
I *do* care that this function catches an error anyway: I need to handle it or throw it before I can get to that sweet -> T type I actually want
2 replies 0 retweets 0 likes -
Replying to @withoutboats @ManishEarth and
In contrast, when a function throws I get my -> T with no work, I have the option to catch the error or just let it keep throwing
1 reply 0 retweets 0 likes -
Replying to @withoutboats @ManishEarth and
Using catch instead of throw emphasizes the core distinction between this proposal and exception based systems
2 replies 0 retweets 0 likes -
That's a point against throws, not a point for catches. How about "T errors E"? A more neutral term imo.
1 reply 0 retweets 1 like -
Replying to @ManishEarth @withoutboats and
how is this more ergonomic? We’re like 2 characters away from writing Result? (The comma, and a GT/LT) otherwise character count is identical. One just muddies the water that your getting a sumtype return value making is implicit.
1 reply 0 retweets 1 like -
Replying to @valarauca1 @ManishEarth and
Sorry to clap at you but
ergonomics
is
not
about
character
count3 replies 0 retweets 1 like -
Replying to @withoutboats @valarauca1 and
I'm no Rust developer, and I agree with the character count thing, but the new `T catch E` for `Result<T,E>` thing does beg some explanation as to how it's more ergonomic. to me it just seems to add complications to the language. But I haven't taught Rust yet, only learned it :)
2 replies 0 retweets 0 likes -
Replying to @radix @withoutboats and
It's aiming for a unification around errors where many people can use `?` and `catches` (or equivalent) as the main way of thinking about error flow. If you don't think that will happen, that's a good objection.
1 reply 0 retweets 1 like -
Replying to @wycats @withoutboats and
I don't know, maybe? I mean, there a bunch of combinators and other methods on Result that are used all over the place, so people are still going to need to know about the type
1 reply 0 retweets 0 likes
It's similar to how you might want to use methods on futures, but it's nice to have `async / await` sugar.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.