Rfcs: Add `Match` trait and combinators

[chachacha3]

Add new Match trait that can be used on enums. The trait will add next functions:

• match() (or into_match())
  
  
  
  • Transforms an object into Match implementation
  
  
• in_case()
  
  
  
  • with argument like in pattern matching with arms usage (or using any other form)
  
  
• otherwise() (or default(), or any other name)
  
  
  
  • Specifies default actions for any other case.
  
  
• probably another ones
  Most parts of code will be simplified and be like that(assuming property1 is a enum):

let some_cased_object = object.propery1.match().in_case(Enum::SomeVariant => { /* do something */ }).in_case(...).default(|| { /*do something you want otherwise*/ });

[rudolfschmidt]

What I do not appreciate in this repo is the little culture in constructive feedback. Just expressing rejection or contempt has nothing to do with evolving a project into a positive direction. At least someone can explain clear and simple why it is a bad idea to implement such a request. Everyone should be free to express his suggestions.

The intention of the writer is to have a less verbose way to write match statements for enums I guess. This is something you can acknowledge first. But it's discussable if there could be a way to write something like

match enum_object {
  Enum::TypeA => true,
  Enum::TypeB = false
  _ => false
}

as a one-liner.

Correct me if I am wrong but if I understood you this is the intention of your proposal?

[crlf0710]

@rudolfschmidt

But it's discussable if there could be a way to write something like

There is one already: matches!(enum_object, Enum::TypeA) and this has been stablized.

What I do not appreciate in this repo is the little culture in constructive feedback.

Nowadays, zulip and internals.r-l-o are for discussions, and github issues are more used for tracking and recording (for future search).

[lzutao]

It is downvoted because the OP doesn't provide the full details, thoughts on the issue:
I will ask something like:

• Reason: What would oneline match bye us? Does it provide benefit over current match?
• Does the same feature appear in other languages?
• What is the tradeoff?
• How complicated is it to implement?

[lebensterben]

You can implement a trait on a concrete enum, e.g. enum Foo {/*...*/}, but you cannot implement a trait on a generic enum type. There is just no such prototype enum type.

So at least for implementation, it doesn't seem possible or easy to devise the proposed trait.

[clarfonthey]

What I do not appreciate in this repo is the little culture in constructive feedback. Just expressing rejection or contempt has nothing to do with evolving a project into a positive direction. At least someone can explain clear and simple why it is a bad idea to implement such a request. Everyone should be free to express [their] suggestions.

So, I don't 100% agree with the assumed intent behind your comment, but I agree that folks should try and spend more time providing details on why they don't think a particular implementation is a good idea.

That said, a lot of us have the time to browse through issues and provide feedback but don't always have the time to write out in-depth explanations, and I think that simply voting for whether you like or dislike a proposal is fine and not done with any sort of malice.

My main reason for downvoting is it appears that the author is trying to provide a way to generalise match statements via a trait, but imho this would make match statements less useful and less clear.

If you boil match statements into a series of checks for conditions, those should be done via guards or if statements. Or, if you're trying to automatically convert the value before matching, then you should just call the function directly and pass it to the match statement. If there isn't the ability to optimise the match into a table lookup of some kind it loses the usefulness of it IMHO.

[scottmcm]

I'm going to close this as inactionable right now. Feel free to reactivate with more details of exactly what this should do, why the methods are better than a match, and why it can't be a crate with a Match trait and a proc-macro derive for it.

From the example, right now this is seemingly adding a whole bunch of new language surface. For example,

.in_case(Enum::SomeVariant => { /* do something */ })

There's currently no _expression_ in rust that looks like a match arm like that. This would need to explain, at a minimum, what that expression _is_: what's it's type? how's it parsed? ...