search

Crell / enum-comparison

A comparison of enumerations and similar features in different languages
82 stars 7 forks source link

Pattern matching design considerations #13

Closed bwoebi closed 3 years ago

bwoebi commented 4 years ago

I think it's sort of okay to bring the pattern matching as a separate RFC, but a well thought out design for pattern matching should exist beforehand, so that they can be nicely integrated at some future point without having to realize fundamental shortcomings in enums with associated values later on.

I wish to see couple a solid examples of it and why they would work out.

iluuu1994 commented 4 years ago

I agree. While pattern matching doesn't need to be part of this RFC we should know exactly what we want to do with it, preferably with a working implementation. There's still a risk of only one of the RFCs being accepted though. I'm not sure if there's a better approach here.

bwoebi commented 4 years ago

While that risk is there, we need to have at least a viable path. If the pattern matching RFC ends up rejected, we can still tweak that RFC and give it another try later on, but if we do a viable attempt at it right now, we at least aren't going to be blocked by our own design decisions later on.

Crell commented 4 years ago

Some prior brainstorming on pattern matching: https://gist.github.com/Crell/58f6ca9c3cdb7f86912adca5bc389f4d

Crell commented 3 years ago

Current thinking is here: https://wiki.php.net/rfc/pattern-matching

I'm going to close this ticket for now. I'm sure pattern matching will be its own ball of wax when the time comes.