[IDEA] Implied enum types

[NullifiedJosh]

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);

[eggyal]

FWIW you can of course use Target::*;, which is how the standard prelude brings the variants of the Option and Result enums into scope.

[CAD97]

Just ::World doesn't work well, because ::name is already allowed, with the semantics of name being the name of an external crate.

[scottmcm]

Reusing my posts from the last few times:

Auto infer namespaces on struct and enum instantiations

This is true for C enums, but is not my experience for Rust enums -- because they're so much richer they often also have extensive and interesting methods and trait implementations too. For a braced struct, I find that I often care less about the type name than for enums, because the field names help. .Skip doesn't tell me nearly as much as CookieHandling::Skip, but .{ window_length: 4096, dictionary_size: 1 << 16, level: 9 } is useful without knowing that those are on a CompressionOptions st…

[Pre-RFC] Inferred Enum Type

To me, the awkward thing about adding this is that it could easily lead to needing to change the conventions for how variants are named. Something like make_webrequest(CookieHandling::Skip) is perfectly readable, but make_webrequest(_::Skip) is pretty confusing. So because the latter syntax doesn't exist, a variant name of Skip is reasonable today, but might not be good later. But if people end up wanting to do _::SkipCookies, that's the kind of repetitive naming (CookieHandling::SkipCookies)…

Enum path inference with `_Variant` syntax

Well, the whole existence of inference is about not writing types, as is method syntax. It's interesting that it's .map(|x| x.ok()), but .map(Result::ok). If _::Variant works, though, should .map(_::ok) work too? I don't know. Here's a previous post with a bunch of examples of places where inference already allows APIs that can do things without saying the types involved: But the situation that seems most clear to me is in struct literals. Options { cookie_handling: CookieHandling::…

[NullifiedJosh]

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 .

[jjpe]

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.

[17cupsofcoffee]

@NullifiedJosh

If so, one of my main ideas was to use IDE intelligence to display the actual enum.

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).

[robinm]

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.

[NullifiedJosh]

@17cupsofcoffee

ne 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).

Yeah, thats where I got my inspiration .

[NullifiedJosh]

That is a very good point. _{only if github had a language server.}

I will research how swift solved this.

[NullifiedJosh]

The problem isn't just the long syntax, it's importing all these files. Also it's not neat.

[NullifiedJosh]

Yup, I wonder what could work in place.

[jjpe]

@NullifiedJosh

it's importing all these files

How are files related to this, other than that the code is contained in one?

[NullifiedJosh]

It's not like a new sytax that requires a new feature, it literally expands from:

use caller::call;
call(/*enums::target */::hello);

To:

use caller::call;
use enums::target;
call(target::hello);

[NullifiedJosh]

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.

[zirconium-n]

@NullifiedJosh

Wouldn't the it be implied by the function you're calling?

If you know the function's signature, then yes. But without an ide, and with unfamiliar code it's often not the case.

@NullifiedJosh

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.

But add a new syntax just to be linted against rustfmt just feels really wrong.

[NullifiedJosh]

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.

[jjpe]

@NullifiedJosh

What I'm saying is that this syntax could be dissalowed in some projects.

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.