[IDEA] Implied enum types

language design
41

I'm trying to find a way to make it a general rule. When I'm next asked to :white_check_mark: an FCP or leave a concern, what's the rule that you want me to be using to decide whether a sugar is ok?

To go back to my set_radio_state(Default::default())?; example, one could easily argue

I'm not convinced that Default::Default() is in any way better than having you write RadioState::default(), just to avoid writing use some_crate::context::RadioState;.

But that's not how Rust works today.

Or, relatedly, we could have required that people say

let x: RadioState = whatever();
set_radio_state(x)?;

to make it easier for the maintenance programmer, but, again, we don't.

What's the general principle that applies to Rust today that would be violated by allowing set_radio_state(.AllBlocked)?;?

(Note that I actually do personally have some concerns about the general feature. But I'd like to focus the bounds on it as much as possible, so there's the possibility for someone to have a clever idea to address the original motivation without the downsides.)

3 Likes