Enum path inference with `_Variant` syntax

[160R]

@scottmcm

Well, the whole existence of inference is about not writing types, as is method syntax.

Method syntax is different because it guaranteedly has receiver expression that usually allows to guess the type. For example foo.bar() communicates nearly the same amount of type information as Foo::bar(foo) and, what matters, it's clear that in most of cases using the former would be redundant. Moreover, the thing on which methods are called has a bigger chance of already being "explicitly typed" e.g. it could be a method argument, new instance of enum/struct, or return value of a generic method like .collect() or .into().

I'd also say that method syntax is either a counterexample, since lack of explicit types allows to easily write confusing code with it. For example long method chains usually are an antipattern and already a lot of discipline is required to know where to introduce a temporary variable, how to name it, etc.

@scottmcm

But the situation that seems most clear to me is in struct literals.

Perhaps the situation when we introduce enum variable could be added to that:

let cookie_handling = .Skip;
...
Options {
    cookie_handling,
    ...
}

But nothing else comes into my mind.

[160R]

@CAD97

All paths, whether namespace::path or field.path go from general to specific.

BTW, the proposed syntax also goes from general to specific. For example in Yes.AllowUnstable the Yes word is more general than AllowUnstable, or in Enabled.Cookies the Enabled word is more general than Cookies and so on. This doesn't match the hierarchy in which things are declared but IMO it's not that important.