On Mon, 13 Apr 2020, Christian Schneider wrote:
> Am 13.04.2020 um 14:41 schrieb AllenJB :
> > As no concerns were raised during the discussion period, the RFC is
> > unchanged from that originally posted.
> >
> > Previous discussion threads:
> > * https://externals.io/message/109015
>
> For
Hi Ilja,
Ilija Tovilo wrote:
Hi internals
I'd like to announce the match expression RFC that replaces the switch
expression RFC I announced a few weeks ago.
New: https://wiki.php.net/rfc/match_expression
I like this proposal in general, I've wanted something like Haskell and
Rust's
> Please, pull that part out.
Guys. You've made your opinions loud and clear. But I'm not just
building this for you, I'm also building it for others and myself.
> With it, it may pass or not, but it would be a weaker proposal.
Maybe, maybe not. You're assuming people will share your opinion
On Mon, Apr 13, 2020, at 10:08 AM, David Rodrigues wrote:
> With all the humility of the world and without wanting to be exhaustive
> about this, my only question is why can't we keep it as a switch, instead
> of creating a new keyword?
That was the original proposal. The main issue came down to
But when we do:
function x() {
$a = function () { return 123; }
}
We know that "return" here is for the current function () scope, and not
for the parents one. So "return" inside inlined-switch should be used to
specify the switch return itself. Seems clear to me.
Atenciosamente,
David
Am 13.04.2020 um 14:41 schrieb AllenJB :
> As no concerns were raised during the discussion period, the RFC is unchanged
> from that originally posted.
>
> Previous discussion threads:
> * https://externals.io/message/109015
For the record: I did raise concerns in
With all the humility of the world and without wanting to be exhaustive
about this, my only question is why can't we keep it as a switch, instead
of creating a new keyword?
$x = switch ($y) {
case 0: return 1;
case 1: return 20;
// default: return null;
};
I say this because, in the
On 13/04/2020 12:28, Ilija Tovilo wrote:
It would be possible for the blocks to return values (though not with
the return keyword).
[...]
We can't do everything at once.
Then why not introduce the match expression first, and add block
expressions (as a general concept) later? That way, we
Hi all,
I have opened voting on the RFC to change the default PDO error mode:
https://wiki.php.net/rfc/pdo_default_errmode
As no concerns were raised during the discussion period, the RFC is
unchanged from that originally posted.
Previous discussion threads:
*
> Firstly, block expressions are a foundational part of the Rust
> language, not a special case used in only one place.
>From a previous e-mail:
> It would be possible for the blocks to return values (though not with
> the return keyword). I've created a small prototype a few weeks ago:
>
>
On 13 April 2020 09:38:10 BST, Ilija Tovilo wrote:
>It's described in the RFC:
>
>//> Fatal error: Match expressions that utilize the result value can't
>contain statement lists
Thanks, I missed that. Reasonably clear, I guess, although I imagine there'll
be questions on Stack Overflow asking
Hi Rowan
> That means if we want to add a way to get a value out of a statement block,
> we can't use "return"; and if we want to add explicit fallthrough, we can't
> use "continue".
And we probably shouldn't do that. return means return from the
function, it makes little sense to change it in
12 matches
Mail list logo
