[VOTE] match expression

On Sat, 25 Apr 2020 at 11:40, Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

Hi Ilija, I like this idea, and would like to see 'match' in PHP. At the same time, is there any need to have the vote right now? The deadline for PHP 8 feature freeze is July 27 2020. There were changes to the proposal overnight, which people have not even had a chance to read, let alone think about. To me it feels like the RFC is being rushed to a vote, with respect to the recent changes and the technical problem you describe.

It also seems the voting options were also changed last night. - The vote is a straight Yes/No vote for accepting the RFC and merging the patch. + "Would you like to add match expressions to the language?" + "Should the semicolon for match in statement form be optional?" + "Should we allow dropping (true) condition?" I think it would be better to continue the conversation and work through the trade-offs when voting isn't active, rather than just hoping people pick the correct choices, or have a contentious time-limited discussion. cheers Dan Ack

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

Hi Ilija, 1. I was confused by the vote announcement email about what "block statements" meant - https://github.com/php/php-src/pull/5371#discussion_r415079802 > Thus I have decided to move block expressions to a separate RFC. This is clarified in https://wiki.php.net/rfc/match_expression#blocks > **For the time being using blocks in match expressions that use the return value in any way results in a compilation error:** (I personally agree with that change for this RFC introducing `match`) 2. As Dan Ackroyd mentioned, https://wiki.php.net/rfc/howto mentions: > When discussion ends, and a minimum period of two weeks has passed since you mailed internals@lists.php.net in step 4, > consider one day heads up mail on the mailing list and then you can move your RFC to “Voting” status. Other people may read the guidelines differently from me, and I've made small mistakes with the process in the past due to not remembering everything in the howto. (and they're guidelines instead of rules) In the future, I'd recommend: i. After finalizing the changes to the RFC and before starting the vote, email out a summary of what changed on the RFC discussion thread itself (https://externals.io/message/109590 "[DISCUSSION] Match expression") ii. Consider waiting at least 24 hours before starting the vote, extending it if you made more changes to the RFC or implementation. This would give voters a clearer idea of what was being voted on, and give people time to point out issues/blockers/new questions with the new RFC/implementation (if needed). P.S. Although it's obvious voting has started, and some other RFCs kept the title "Proposed Voting Choices", https://wiki.php.net/rfc/match_expression#proposed_voting_choices could be renamed from "Proposed Voting Choices" to "Vote" Thanks, - Tyson

Heya, Just following up here, after private convo on why I voted "NO" on this RFC. My rationale for not wanting the RFC (in its current state) is that I don't want more procedural constructs in the language. Specifically, I'm fine with: match (<expression-to-be-matched>) { <potentially-matching-expression> => <result-expression-to-be-evaluated>, <potentially-matching-expression> => <result-expression-to-be-evaluated>, <potentially-matching-expression> => <result-expression-to-be-evaluated>, default => <result-expression-to-be-evaluated>, } I'm not fine with allowing procedural code to be executed on the right-hand-side of each match. It would still possible to hide procedural code in the right-hand-side of the match, but luckily without affecting the outer scope: match (<expression-to-be-matched>) { <potentially-matching-expression> => (function () { /* insert your procedural nightmare of choice here */ })(), <potentially-matching-expression> => (fn () => /* more procedural nightmares here */)(), default => <result-expression>, } By enforcing only expressions to be on the right-hand-side, we get some nice side-effects too: * no need to discuss `continue` * no need to discuss `break` * no need to discuss `return` Overall, that would be a win-win. A point has been risen about the fact that using closures increases memory usage and stack frames: that's a compiler optimization concern, and probably also a minor one, since I'd discourage procedural code on the RHS anyway :-) I'd be voting YES on the RFC if the blocks were gone. On Sat, Apr 25, 2020 at 12:40 PM Ilija Tovilo <tovilo.ilija@gmail.com> wrote:

Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/