[IDEA] Implied enum types

[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::…