Hi!
I'm referring to support for non-trivial expressions, aka blocks. Say, the
ability to split up a long expression by using a meaningful temporary
variable. Block support is sufficient to cover *most* switch use-cases,
obviating the need to introduce a new switch variant.
We could take a
On Tue, Dec 1, 2020 at 7:57 PM Larry Garfield
wrote:
> On Mon, Nov 30, 2020, at 9:09 AM, Nikita Popov wrote:
> > On Thu, Nov 26, 2020 at 5:39 PM David Rodrigues
> > wrote:
> >
> > > Hello!
> > >
> > > With PHP 8 we have match(), that is a switch strict expression-like.
> But
> > > strict is not
On Tue, Dec 1, 2020, 19:57 Larry Garfield wrote:
>
>
> Disagree. switch is a procedural logic flow control. match is an
> evaluation expression. Things like fallthrough do not belong there, as it
> mushes expressions together in weird ways. match is lovely because its
> logic flow is simple
On Mon, Nov 30, 2020, at 9:09 AM, Nikita Popov wrote:
> On Thu, Nov 26, 2020 at 5:39 PM David Rodrigues
> wrote:
>
> > Hello!
> >
> > With PHP 8 we have match(), that is a switch strict expression-like. But
> > strict is not strict, and it could cause confusion because switch() and
> > match()
On Thu, Nov 26, 2020 at 5:39 PM David Rodrigues
wrote:
> Hello!
>
> With PHP 8 we have match(), that is a switch strict expression-like. But
> strict is not strict, and it could cause confusion because switch() and
> match() are pretty similar.
>
> I believe that this has already been discussed,
On Thu, Nov 26, 2020 at 10:39 AM David Rodrigues
wrote:
> With PHP 8 we have match(), that is a switch strict expression-like. But
> strict is not strict, and it could cause confusion because switch() and
> match() are pretty similar.
>
>
I agree that PHP deserves the ability to do strict
Hello!
With PHP 8 we have match(), that is a switch strict expression-like. But
strict is not strict, and it could cause confusion because switch() and
match() are pretty similar.
I believe that this has already been discussed, but it would be interesting
to re-evaluate the possibility of a
Den 2018-06-14 kl. 11:21, skrev Rowan Collins:
On 14 June 2018 at 09:35, Nikita Popov wrote:
On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote:
Just for casual discussion at this point:
https://github.com/php/php-src/pull/3297
switch ($a) {
case FOO:
// Works exactly as
On Friday, June 15, 2018 9:54:48 AM CDT Theodore Brown wrote:
> On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov wrote:
> > I think if people want to use strict matching, they'll quite likely want
> > to
> > have it on all cases. Something like "strict switch ($expr) {}" or "switch
> > strict
On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov wrote:
> I think if people want to use strict matching, they'll quite likely want to
> have it on all cases. Something like "strict switch ($expr) {}" or "switch
> strict ($expr) {}" or "switch (strict $expr) {}" or "switch ($expr) strict
> {}" or
On 15 June 2018 at 14:48, Jordi Boggiano wrote:
> Might I suggest a new strictwich ($a) { ... } keyword? It's much more
> appetizing.
>
Or maybe we should follow the pattern of == vs === and double up the "s":
"sswitch ($a) { ... }"
;)
--
Rowan Collins
[IMSoP]
On 15/06/2018 00:10, Stanislav Malyshev wrote:
With current tendency to move to more strict interpretation and a bit
away from type juggling, I think it has its place. But I am not a big
fan to putting === there, it looks weird. Maybe go a bit further and
make the whole switch strict?
strict
2018-06-15 11:44 GMT+02:00 Christoph M. Becker :
> On 15.06.2018 at 08:36, Sebastian Bergmann wrote:
>
> > Am 14.06.2018 um 10:35 schrieb Nikita Popov:
> >
> >> It might make sense to introduce an entirely new "match" statement
> >> that conforms a bit more with how switch-like strictures are
>
On 15.06.2018 at 08:36, Sebastian Bergmann wrote:
> Am 14.06.2018 um 10:35 schrieb Nikita Popov:
>
>> It might make sense to introduce an entirely new "match" statement
>> that conforms a bit more with how switch-like strictures are
>> implemented nowadays. That is, something like
>>
>> match
On 14 June 2018 at 23:15, Stanislav Malyshev wrote:
> Hi!
>
> > Would both be more apparent as to its meaning and leave the door open
> > for other uses. Though at that point, tbqh, I think `switch ($a) use
> > (===) {...}` gives better visual isolation.
>
> I don't think we should reuse the
Am 14.06.2018 um 10:35 schrieb Nikita Popov:
> It might make sense to introduce an entirely new "match" statement
> that conforms a bit more with how switch-like strictures are
> implemented nowadays. That is, something like
>
> match ($expr) {
> "foo" => {...},
> "bar" | "baz" => {...},
>
> switch($a){
>case true:
> //will match true, 1, etc...
> break;
>strict case false:
> //will not match anything except boolean FALSE
> //other stuff
> break;
>case false:
> //will match 0, null, etc
> break;
> }
>
I like this syntax, but
Hi!
> Would both be more apparent as to its meaning and leave the door open
> for other uses. Though at that point, tbqh, I think `switch ($a) use
> (===) {...}` gives better visual isolation.
I don't think we should reuse the use() thing for third purpose when
we're already using it for two. I
Hi!
> switch ($a) {
> case FOO:
> // Works exactly as current behavior.
> break;
> case == FOO:
> // Nearly identical, though not using the ZEND_CASE optimization.
> // Can probably make this equivalent to `case FOO`, but it felt
> like an interesting direction.
>
On Thu, Jun 14, 2018 at 12:45 PM Rowan Collins
wrote:
> On 14 June 2018 at 17:16, Alice Wonder wrote:
>
> >
> > Should declare(strict_types = 1) do that?
> >
> > I haven't tried, but I would think it should.
>
>
>
> No, it doesn't, and shouldn't. "strict_types" actually means
>
On 14 June 2018 at 17:16, Alice Wonder wrote:
>
> Should declare(strict_types = 1) do that?
>
> I haven't tried, but I would think it should.
No, it doesn't, and shouldn't. "strict_types" actually means
"non_coercive_scalar_type_hints"; it's a very specific feature, controlling
a specific set
On 06/14/2018 08:57 AM, Thomas Bley wrote:
Nikita Popov wrote on 14.06.2018 10:35:
On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote:
Just for casual discussion at this point:
https://github.com/php/php-src/pull/3297
switch ($a) {
case FOO:
// Works exactly as current behavior.
On Thu, Jun 14, 2018 at 11:57 AM, Thomas Bley wrote:
> for simplicity I would use an extra parameter to have a strict comparison
> (similar to the extra parameter in in_array()):
>
> switch ($a, true) { // strict comparison
> switch ($a) { // loose comparison
>
I instinctively recoil from
Sara Golemon – Thu, 14. June 2018 16:50
> On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov wrote:
> > I like the general idea here (switch with strict type comparison), but not
> > super fond of the particular syntax and implementation.
> >
> No arguments there. What's presented is "best I could
Nikita Popov wrote on 14.06.2018 10:35:
> On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote:
>
>> Just for casual discussion at this point:
>> https://github.com/php/php-src/pull/3297
>>
>> switch ($a) {
>> case FOO:
>> // Works exactly as current behavior.
>> break;
>> case
On 14 June 2018 at 15:48, Sara Golemon wrote:
> Agree that it's more likely to be all-or-not within a switch block.
> If I could step through my thinking in putting it on the case
> statement however, I applied two starting rules:
> 1. Avoid adding new reserved symbols/keywords.
> 2. Try to make
On Thu, Jun 14, 2018 at 4:35 AM, Nikita Popov wrote:
> I like the general idea here (switch with strict type comparison), but not
> super fond of the particular syntax and implementation.
>
No arguments there. What's presented is "best I could come up in the bath". :)
> I think if people want
On 14.06.2018 at 10:35, Nikita Popov wrote:
> On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote:
>
>> Just for casual discussion at this point:
>> https://github.com/php/php-src/pull/3297
>>
>> switch ($a) {
>> case FOO:
>> // Works exactly as current behavior.
>> break;
>>
Apologies - sending again from on-list address.
I’m not overly fond of the `case ===`
Could it be simply `case` for current behaviour and `strict case` for the new
behaviour?
I’d argue that while fall through can cause problems it also has legitimate
uses.
Sent from my iPhone
Sent
On 14 June 2018 at 09:35, Nikita Popov wrote:
> On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote:
>
> > Just for casual discussion at this point:
> > https://github.com/php/php-src/pull/3297
> >
> > switch ($a) {
> > case FOO:
> > // Works exactly as current behavior.
> >
On Thu, Jun 14, 2018 at 6:53 AM, Sara Golemon wrote:
> Just for casual discussion at this point:
> https://github.com/php/php-src/pull/3297
>
> switch ($a) {
> case FOO:
> // Works exactly as current behavior.
> break;
> case == FOO:
> // Nearly identical, though not using
Hi,
On Thu, Jun 14, 2018 at 7:53 AM, Sara Golemon wrote:
> Just for casual discussion at this point:
> https://github.com/php/php-src/pull/3297
>
> switch ($a) {
> case FOO:
> // Works exactly as current behavior.
> break;
> case == FOO:
> // Nearly identical, though not
Just for casual discussion at this point:
https://github.com/php/php-src/pull/3297
switch ($a) {
case FOO:
// Works exactly as current behavior.
break;
case == FOO:
// Nearly identical, though not using the ZEND_CASE optimization.
// Can probably make this equivalent to
33 matches
Mail list logo
