While I understand that is how it is both parsed and stored internally to the compiler, from a user's perspective, it's a type. I can use it in ways that a function can't, such as destructuring.
But with regard to univariant enums? It's definitely questionable at best. Honestly the only reason I even included it was because he mentioned it; otherwise I likely wouldn't have thought of it.
More on single-variant enums: it reminds me of derive(Default) not working on them, even though it certainly could.
It's a complicated question. Because for example in (0..10).map(Wrapping), it's far more a function than a type. Would let v: Vec<Wrapping<i32>> = (0..10).map(_).collect(); work, inferring a tuple-struct-constructor? That one feels like a stretch to me.
I agree it's less of an issue in patterns than it is in expressions.
Imo it feels like it should. Reasonable minds can disagree, of course.
I would say that that would be too "magical" because there might be multiple functions for doing the conversion.
I, personally, feel that this should be only added to patterns.
How do people feel about restricting this (initially?) to only patterns? This would cover some of the larger use cases, including function parameter destructuring, while avoiding hinge like value construction. From my previous comment, this would allow alpha, beta, and gamma, but not the rest. Nested usage should be allowed.
I'm torn. On the one hand it makes sense as the simpler case. On the other hand, the usual parallels between expressions and patterns mean that accepting it for patterns would set such strong precedent for expressions that perhaps it ought to be considered at the same time to avoid a potential future where a different approach needs to be picked for expressions because of complications.
For example, imagine if the expression side ended up needing to be struct(5) or enum::V4(ip) instead of _(5) or _::V4(ip) to avoid ambiguity. Then might be better for the pattern side to be that too, even if the underscore syntax would work fine there. (I really worry about things like _::new(4) getting requested, like C#'s new inferrered-new feature, depending how broadly this elision starts to apply.)
I think it's a fallout from wanting to show parameter names. Basically it's stuck showing either the actual pattern or arg1, and I guess it prefers the former.
There are already enough differences between patterns and expressions that this would be acceptable. Most notably, the wildcard (_) is currently only allowed in patterns (although for different reasons).
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.