[IDEA] Implied enum types

[scottmcm]

@farnz

My overriding rule is around locality of reasoning - anything that forces me to reason non-locally is problematic by design, since I know that software developers generally aren't great at non-local reasoning (we rely on heuristics like "that's what a similarly named bit of code in a codebase I worked on 10 years ago did"). Applying that overriding rule to implicitness, the general rule I'd like you to apply is that increasing implicitness should not also increase the room for non-local ambiguity.

Aaron called this "context-dependence" in his classic post on the Reasoning Footprint.

The example about type annotations describes it thusly:

Context-dependence: because data types and functions are annotated, it's easy to determine the information that's influencing the outcome of inference. You only need to look shallowly at code outside of the current function. Another way of saying this is that type inference is performed modularly, one function body at a time.

I would say that "look shallowly" is a good description of what's needed for implied enum types. After all, even set_radio_state(RadioState::Enabled)? isn't just local, because RadioState itself would often come from a use, forcing you to look elsewhere in the file.

Looking at the other two axes:

• Applicability: I use the set_radio_state(.Enabled)? syntax in my posts here to give it that "heads-up that this [is] happening". And it's only elidable where inference has already determined what the type must be -- dbg!(.Enabled) would never work.

• Power: Because it only works where the type is already forced by something else, this can't "radically change program behaviour or its types".

So yes, this does have some impact on locality of reasoning, but not a particularly bad one -- far less than trait method resolution, for example. And it's low impact on the other axes, so I see it as fitting well in the kinds of tradeoffs that Rust has generally been happy to make.

I think, instead, that this is the core issue:

@farnz

I'm using bad naming because I'm trying very hard not to break NDAs relating to real code, while still giving an example that shows the essence of the problem.

My personal concern with this, as I linked above, is entirely about naming:

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

The problem is not in locality of reference, but in naming conventions.

Calling foo(.Yes, .Yes) is as bad as foo(true, true), but people make enums like that today because this feature doesn't exist (see InheritStability::Yes and InheritDeprecation::Yes, for example), and thus the call would be foo(InheritStability::Yes, InheritDeprecation::Yes), which is entirely readable.

Thus to me, if Rust was designed around this feature it wouldn't be .Disable, but .DisableRadio, and you'd solve your update problem by removing the Disable variant and calling it DisableWifi or DisableAllRadios, so you still get the compiler error for the callsites, just in a different way.

Therefore I think the big unknown here is in how to get the goodness of not needing to say the irrelevant when it's irrelevant, but still make sense with the general non-stuttering scoped nature of enums in existing Rust. The non-localness, by itself, is not the issue.

(And, of course, there's the big overarching question of whether the language grammar needs to ensure this, or whether -- like foo(true, true) -- the appropriate mitigation might just be code review.)

@farnz

I would also note that I can make the same argument as you're making about enum types with respect to unsafe

I consider this a false parallel, because the potential impacts are so different. UB makes it impossible to reason about your program, because a program that hits UB is allowed to do literally anything. Getting a variant from the only enum that can possibly be passed to a function is of tiny impact, relatively.

Logic errors are always possible, but when it's just a logic problem and not UB, then logging and debuggers and testing and such are meaningful.