Please note that this is my first time using this forum.
I saw a similar issue, but it was closed due to inactivity.
Feature Name: Implied enums
Summary
A proposal to allow enums to be implied when inputting parameters.
Motivation
When I tried swift I noticed how simple it was to call functions without having messy enum definitions taking up space. I have used this syntax and believe it is quite convenient.
I have seen a similar issue but it has been closed.
Proposed solution
I think we could have a similar syntax that could fit with the rust language.
enum Target {
Everyone,
World
}
fn greet(target: Target) {
println!("Hello {}", match target {
Everyone => "everyone",
World => "world"
});
}
fn main() {
greet(::World);
}
I think all implied enums should be like this rather than maybe an _:: because IDEs can show the implied enum:
Prior art
Swift syntax:
enum Target: Int {
everyone = 0
world = 1
}
// Yes, you could use "rawvalue" but this is an example
func greet(target: Target) {
switch target {
case .everyone:
print("Hello Everyone!")
case .world:
print("Hello World!")
}
}
greet(.world);
Sorry, you mentioned many different things within these posts. I see that you are saying this won't work because of:
Rust enums being different
Unclear code
Is this correct?
If so, one of my main ideas was to use IDE intelligence to display the actual enum.
For rust enums being different, couldn't we just import them in the background?
Also I have seen the playground but this doesn't seem relevant doc.
As stated, I'm new to this forum, please help me understand .
There's also an argument that it goes against what's considered idiomatic in Rust code. You see, one of the values of Rust is to be explicit. As convenient as the feature might sometimes be, implicit enums wouldn't mesh very well with that value IMO.
Aside from that, earlier in this topic the (quite valid) point was made that you can just use use MyEnum::*;, after which you can just use the unqualified enum variant names. That is perfectly workable in practice when things would get too verbose otherwise.
I'd be wary of relying too much on IDE hints for readability - not everyone uses IDEs/language servers, and there's a lot of scenarios where you might need to read code without one (for example, a code review on GitHub).
There was also proposals to have greet(_::World); but so far they have not reach consensus. One point that was against it is that in Rust it’s idiomatic to not have the enum name repeated in the variants and eliding the enum name could to do it (like Action::ActionDown). That being said, I think that in match expression it would be useful to elide the enum name since it’s already clear about which enum we are talking about.
Wouldn't the it be implied by the function you're calling? Also, there are many ways to write unreadable code in rust and just like many other things, it could just be fixed by rustfmt or just a rule in rustfmt. It's opt-in. Not required O_o.
Also I think the syntax _:: is actually pretty nice and I think it would work well.
That's not what I meant. What I'm saying is that this syntax could be dissalowed in some projects. Me and many other people would want to keep it on though.
What this refers to is the phenomenon of language dialects. C++ has it, but only by "virtue" of being so complex and so full of footguns that just out of pragmatism choices need to be made w.r.t. which features to use and which to avoid.
This is something I personally consider undesirable, as it just increases project complexity without a clear benefit in return.