Re: [VOTE] match expression

> Am 25.04.2020 um 12:39 schrieb Ilija Tovilo <tovilo.ilija@gmail.com>: > > Hi internals > > I have opened the voting on the match expression RFC. It will end on > 9th of May, 2020. > https://wiki.php.net/rfc/match_expression > > Here are the last changes: > > In the last update I mentioned allowing return values in blocks. > Unfortunately, we discovered some technical difficulties (memory > leaks) which are very hard to solve. Nikita is experimenting on a > possible solution. There was also a fair bit of backlash over the > syntax. Thus I have decided to move block expressions to a separate > RFC. Note that blocks with just statements remain part of this RFC. > > The "duplicate condition" warning mentioned by Dan was removed due to > the arguments made by Tyson. > > I have also moved the optional semicolon for the match in statement > form to a separate vote as this was another controversial part of the > proposal. > > Furthermore I have added another secondary vote for allowing to drop > (true) conditions as that was suggested multiple times: > > match { > $age >= 30 => {}, > $age >= 20 => {}, > $age >= 10 => {}, > default => {}, > } > > // Equivalent to > > match (true) { > $age >= 30 => {}, > $age >= 20 => {}, > $age >= 10 => {}, > default => {}, > } > > There is a separate poll for specifying the reason for a "no" vote. > Let me know if there are any other reasons so I can add those to the > poll. > > A personal thank you goes out to Tyson for his guidance! > > Regards, > Ilija Hey Ilija, while in general I'm okay-ish with match using a strict comparison, shall the "match { $cond1 => {}, $cond2 => {} }" syntax be strict or not? I would do a simple truthiness check in that particular case (which IMHO is also consistent as there is no explicit value it's compared against). That way it would essentially have the semantics of a chained ternary without being illegible. At least as match {} without explicit expected value is effectively a boolean comparison (doesn't feel really like a strict value comparison), it should also behave like a classical boolean comparison. In general, apart from that very last change (I think you should have given it at least 1-2 days of consideration before starting the vote), the RFC is nice and provides a concise syntax for something which usually is quite uglily expressed. Bob