“I think we should reject new proposed language features that use closures because closures are slow” *head explodes*
-
-
-
-
-
Replying to @ManishEarth @pcwalton
Performance aside, I hope no form of this proposal is accepted. Sum types just don't fit in to the design of the language.
3 replies 0 retweets 0 likes -
Replying to @BrandonBloom @pcwalton
Why not? I know plenty of gophers who want sum types in Go. I've often seen the interface hack used for making sum types.
1 reply 0 retweets 0 likes -
Replying to @ManishEarth @pcwalton
No pattern matching; preference for open unions (interfaces) without wrappers; no generics; preference for label-indexed record fields; ...
3 replies 0 retweets 0 likes -
And it's just not a practical need. For unexpected errors, wrap then in funcs that panic. For expected errors, no-op propagation is rare.
2 replies 0 retweets 0 likes -
Most propagation operator usages in Rust is a failure to add error context. Every if/err/return is an opportunity to do so.
2 replies 0 retweets 0 likes
Good thing the ? operator was explicitly designed to allow you to add error context then!
-
-
Replying to @pcwalton @ManishEarth
I'm skeptical automatic context based on implicit type conversion is better than a human written string. Doubly skeptical worth complexity
1 reply 0 retweets 0 likes -
Replying to @BrandonBloom @ManishEarth
The choice is between automatic type conversion and devs not bothering to add context at all. Evidence: Go.
1 reply 2 retweets 4 likes - 1 more reply
New conversation -
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.