3 ms·
I'm not really up to speed on what the Rust team is thinking, but basically no. These are not the kinds of things the Rust team would do to improve ergonomics.
by brson 8y ago
I'm not really up to speed on what the Rust team is thinking, but basically no. These are not the kinds of things the Rust team would do to improve ergonomics. Correctness is forefront in Rust. The only thing I can think of like this op that has seriously been considered is automatic cloning for trivial types like `Rc`.
The Rust team thinks really hard about correctness before making any decisions and isn't going to add any ridiculous footguns to the language unless there's some organizational catastrophe that puts monkeys in charge of decision making.
- phaylon 8y agoI'd say there are a couple of things that apply: * `?` can propagate values/short circuit control flow, but it also contains a hidden type conversion. The target needs to be a known type for it to compile. * A proposed `catch` construct will include implicit type conversion for its result value. Some things that came up in the past but met resistance: * Removing project structure from in-code to being defined by the filesystem. * Hiding `Result` types in signatures with special syntax. * Dropping immutable by default, though this was pre-1.0. Also, `Rc` and `Arc` are good examples for this. They do seem trivial, but having them auto-clone would mean: * Every newcomer who writes `fn foo(val: Arc<Bar>) {}` instead of `fn foo(val: &Arc<Bar>) {}` or `fn foo(val: &Bar) {}` will get an implicit atomic increment/decrement at every function call. * It also makes it a lot harder to reason about code if you want to use a clone-on-mutation-unless-not-shared strategy.
- hyperpape 8y agoI think RC examples are very good, but in the case of special syntax for Result, isn’t that a case where the two options are semantically the same, you just are wary of the less verbose/loud option (I have withoutboats’ post in mind here)?