Larry Garfield wrote:
On Sun, Mar 29, 2020, at 4:04 PM, Ilija Tovilo wrote:
What you're proposing is a language construct for an *expression*,
which evaluates depending on internal logic to a different value.
Those are sufficiently distinct that I agree they should have distinct
keywords. Plu
Hi Larry
> Not everything has to be a statement.
This is not what I meant. What I meant is that it should be usable in
a statement context. Since you mentioned Rust, match is always an
expression. But you can use it without making use of the return value.
This is what I'm suggesting. In PHP this
On Sun, Mar 29, 2020, at 5:07 PM, Ilija Tovilo wrote:
> Hi Larry
>
> Thanks for your suggestion.
>
> I chose to use switch instead of match for a couple of reasons:
>
> 1. It uses the same AST, code generation and opcodes as the switch, I
> don't agree that it is significantly different than the
Hi!
> 1. It uses the same AST, code generation and opcodes as the switch, I
> don't agree that it is significantly different than the switch that we
> already have.
This is reasoning in wrong direction. Nobody cares which opcode it uses.
It is significantly different *for the user*, the fact that
Hi Larry
Thanks for your suggestion.
I chose to use switch instead of match for a couple of reasons:
1. It uses the same AST, code generation and opcodes as the switch, I
don't agree that it is significantly different than the switch that we
already have.
2. Adding the `match` keyword is a break
On Sun, 29 Mar 2020 at 23:54, Stanislav Malyshev
wrote:
> Hi!
>
> > My recommendation would be to just borrow Rust's keyword:
> >
> > $result = match ($var) {
> > $expression => $expression;
> > $expression => $expression;
> > $expression => $expression;
> > default => $expression;
> > }
Hi!
> My recommendation would be to just borrow Rust's keyword:
>
> $result = match ($var) {
> $expression => $expression;
> $expression => $expression;
> $expression => $expression;
> default => $expression;
> }
Yes, this would be much better idea.
--
Stas Malyshev
smalys...@gmail.com
On Sun, Mar 29, 2020, at 4:04 PM, Ilija Tovilo wrote:
> > Having two syntaxes for one keyword is not a good idea,
>
> We're already doing that. What about classes vs anonymous objects?
> Functions vs closures?
> They're using the same keywords. There's no confusion.
>
> Ilija
There's subtle and
On Sun, 29 Mar 2020 at 23:04, Ilija Tovilo wrote:
> > Having two syntaxes for one keyword is not a good idea,
>
> We're already doing that. What about classes vs anonymous objects?
> Functions vs closures?
> They're using the same keywords. There's no confusion.
>
> Ilija
>
> --
> PHP Internals -
> Having two syntaxes for one keyword is not a good idea,
We're already doing that. What about classes vs anonymous objects?
Functions vs closures?
They're using the same keywords. There's no confusion.
Ilija
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://
Hi!
>> I'm still not sure why if we're calling it "switch"
>
> C# does it. Not to say everything they do is right but it's reassuring
> that a big company like Microsoft had the same approach.
No it isn't. Having two syntaxes for one keyword is not a good idea,
whether Microsoft is doing it or n
Hi Stanislav
> I'm still not sure why if we're calling it "switch"
C# does it. Not to say everything they do is right but it's reassuring
that a big company like Microsoft had the same approach.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/switch
https://docs.micros
Hi!
> You can take a look at the tests to get a feel for what it’s like:
>
> https://github.com/php/php-src/pull/5308/files
>
> Multiple conditions are possible:
>
> ```
>
> return $day switch {
>
> 1, 7 => false,
>
> 2, 3, 4, 5, 6 => true,
>
> };
I'm still not sure why if we're ca
Hi Gabriel
> This doesn't look like it can do fallbacks which are traditional feature of
> switch statements, can it?
You can take a look at the tests to get a feel for what it’s like:
https://github.com/php/php-src/pull/5308/files
Multiple conditions are possible:
```
return $da
This doesn't look like it can do fallbacks which are traditional feature of
switch statements, can it? What I mean is this
```
case foo:
case bar:
return 1;
case baz:
return 2;
```
If we can't do that, I would suggest to go with different name, rather
than reusing "switch".
Hi, internals,
En mié, 25 mar 2020 17:21:29 +0100 Rowan Tommins
escribió
> On Wed, 25 Mar 2020 at 15:29, Ilija Tovilo wrote:
>
> > I don't think this would add any significant benefit over:
> >
> > ```php
> > $x = true switch {
> > $x !== null && $x < 5 => ...
> > }
>
On 25.03.2020 at 17:06, Dennis Birkholz wrote:
> Hello together,
>
> Am 25.03.20 um 16:46 schrieb Larry Garfield:
>> On Wed, Mar 25, 2020, at 10:29 AM, Ilija Tovilo wrote:
>>> Thanks for your feedback, Larry!
>>>
One possible improvement to either version is allowing an expression on
the
Hi Rowan
> The problem with that is that it requires a temporary variable to be
> switched on. If I want to switch on, say, a method call, I can write this
> for equality:
I agree. The iffy part would be recognizing if the case expression should be
equated to the switch input or evaluated on its
Hi Dennis
Thanks for your feedback!
> you can fall through to other cases without break
You could do the same using the || operator.
> what about the default case?
I haven't described the default case in my proposal but it is exactly what
you'd expect it to be:
```php
$var = true switch {
On Wed, 25 Mar 2020 at 15:29, Ilija Tovilo wrote:
> I don't think this would add any significant benefit over:
>
> ```php
> $x = true switch {
> $x !== null && $x < 5 => ...
> }
> ```
>
The problem with that is that it requires a temporary variable to be
switched on. If I want to switch on
Hello together,
Am 25.03.20 um 16:46 schrieb Larry Garfield:
> On Wed, Mar 25, 2020, at 10:29 AM, Ilija Tovilo wrote:
>> Thanks for your feedback, Larry!
>>
>>> One possible improvement to either version is allowing an expression on the
>>> left side. That is, rather than doing an equality match
On Wed, Mar 25, 2020, at 10:29 AM, Ilija Tovilo wrote:
> Thanks for your feedback, Larry!
>
> > One possible improvement to either version is allowing an expression on the
> > left side. That is, rather than doing an equality match, do a boolean
> > match.
>
> This is how Rust does it:
>
> ``
Thanks for your feedback, Larry!
> One possible improvement to either version is allowing an expression on the
> left side. That is, rather than doing an equality match, do a boolean match.
This is how Rust does it:
```rust
let x = match ... {
Some(y) if y < 5 => ...
}
```
In other words,
On Wed, Mar 25, 2020, at 9:27 AM, Ilija Tovilo wrote:
> Hi Michał
>
>
>
> I’m sorry, unfortunately I missed your e-mail and RFC.
>
> Let me know if you’re still working on it and I’ll back off of course.
>
>
>
> Regards
I like the concept, and it looks like you're both on a similar track.
Hi Michał
I’m sorry, unfortunately I missed your e-mail and RFC.
Let me know if you’re still working on it and I’ll back off of course.
Regards
Hi Ilija,
śr., 25 mar 2020 o 13:10 Ilija Tovilo napisał(a):
> Hi everybody!
>
>
>
> A few years ago I suggested adding a new `match` expression to the PHP
> language:
>
> https://externals.io/message/100487
>
>
>
> I arrogantly assumed someone will implement it for me which of course
> didn't ha
Hi everybody!
A few years ago I suggested adding a new `match` expression to the PHP language:
https://externals.io/message/100487
I arrogantly assumed someone will implement it for me which of course didn't
happen. I'd finally like to get my own hands dirty. I have a very rough,
incompl
27 matches
Mail list logo
