Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:112304
MIME-Version: 1.0
References: <CAEsg9X1JmNm22NSi=q6=oZD2=WtZy1CwWRCYUW5NrPG6AjBP7w@mail.gmail.com>
In-Reply-To: <CAEsg9X1JmNm22NSi=q6=oZD2=WtZy1CwWRCYUW5NrPG6AjBP7w@mail.gmail.com>
Date: Thu, 26 Nov 2020 11:38:18 -0600
Message-ID: <CAESVnVrCy21mH3tvt_xCtmDyqngWtuGX15dQWaB61xRimPp2Dg@mail.gmail.com>
To: David Rodrigues <david.proweb@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000013df7805b50603fe"
Subject: Re: [PHP-DEV] Strict switch
From: pollita@php.net (Sara Golemon)

--00000000000013df7805b50603fe
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 26, 2020 at 10:39 AM David Rodrigues <david.proweb@gmail.com>
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 comparisons when
requested and that match won't serve all of switch's use cases.  This idea
has come up a few times in the past, but I think we can perhaps get further
with it now that the language is growing more strict-friendly.


> (1) strict switch(8.0) { case '8.0'; return 'no'; case 8.0: return 'yes'; }
> // yes
>

Introducing new keywords automatically has a higher bar to acceptance than
not, so while this certainly reads well, we do have to consider the impact
to existing code defining clases/functions named 'strict'.


> (2) switch strict(8.0) { ... } // yes
> (3a) switch(8.0, true) { ... } // yes
>

I'm not a fan of how either of these read.  The first on wholly aesthetic
grounds, the latter on opacity.  The meaning of "true" is inobvious here.


> (3b) switch(8.0, strict: true) { ... } // yes (named argument)
>
>
This I like now that we have named arguments.  It's a psuedo named
argument, but I don't think that distinction matters too much from the
userland perspective.  Implementation might be a little on the ugly side
though, so let's keep it in the maybe pile.


> Or then in the "case":
>
> (4) switch(8.0) { strict case 8.0: ... } // yes
> (5) switch(8.0) { case strict 8.0: ... } // yes
>
> Or allowing operators (this would be the most flexible way, as it would
> allow for a number of other features):
>
> (6) switch(8.0) { case === 8.0: ... } // yes
>
>
These formats have been proposed previously, and I think they're the worst
of the lot because now you have a comparison that is potentially sometimes
strict and sometimes not.  This has the highest potential for surprise.


The main question I'd put to you is this:  Are there other parts of the
language where a strictness modifier would also make sense, or is it unique
to `switch`.  I suspect it's not, so list out those syntaxes and identify
how the proposed options would translate to them.  A general purpose winner
may float itself to the top.

-Sara

--00000000000013df7805b50603fe--