Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender)
To: internals@lists.php.net
References: <eb28362c-4f8f-45df-bbf0-582e8ad2b8af@Spark>
 <DM3PR18MB07647618E0682A20C05C255FDE6B0@DM3PR18MB0764.namprd18.prod.outlook.com>
 <CANUQDCg-gUUpvpgq-PR4xzf9spMiS+AH+L8FhN9gBkcrohQryw@mail.gmail.com>
 <DM3PR18MB07645D39FC3D93B73935FC9CDE6B0@DM3PR18MB0764.namprd18.prod.outlook.com>
 <044d6dc6-63b4-5242-b910-f5a4fdf48eab@rhsoft.net>
 <CAObuZdtSzV8Ccv5nzRJG30CQWLJ6+zxsNA5k036L5tOX3ezLkQ@mail.gmail.com>
 <66a056cc-87f6-3f5e-0417-6b8ab51cdbae@rhsoft.net>
 <ca3e218e-3f5e-3d16-7633-27f861a84f04@gmail.com>
Message-ID: <94abb2fb-5d18-534e-4da4-4dde187ac494@rhsoft.net>
Date: Mon, 11 Sep 2017 01:36:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <ca3e218e-3f5e-3d16-7633-27f861a84f04@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-CH
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Match expression
From: lists@rhsoft.net ("lists@rhsoft.net")



Am 10.09.2017 um 22:35 schrieb Rowan Collins:
> On 10/09/2017 20:35, lists@rhsoft.net wrote:
>> with "<?php declare(strict_types=1);" the intention is pretty clear 
> 
> strict_types does not currently have any effect on comparisons anywhere, 
> and nor is it likely ever to do so. It is a very specific option, not a 
> broad set of behaviours like "use strict" in JS or Perl.

in case of a normal comparison you have !== and === to make it explicit

>> raise an error if cases are mixed (case 'a' and case 1 under  the same 
>> switch)
> 
> It's interesting that the behaviour you think is obvious is completely 
> different to what I think of: if the author of the code has put both 
> case 42 and case '42' in the switch statement, the "strict" 
> interpretation in my mind would be that both branches are reachable, as 
> though tested with an "===" operator (whereas currently the second would 
> never be selected, because no value =='42' that doesn't also ==42).

yes, for non-strict code that's fine

>> and also raise an error in a case like below when $a is  anything else 
>> then int
> 
> I guess this explains the different direction you're coming from: what 
> you want could perhaps be termed a "strongly typed switch statement", 
> where both input and case values are checked as soon as possible for 
> being of some specified type.

yes, that's what i expect from declare(strict_types=1); wherever it is 
possible for several reasons

* as developer i like fail early and raise a clear exception
* in the best case even at compile time and not 3 days later at runtime
* it makes code often more secure over time when it points
   out missing input validation and from where a bad value comes
   instead burry a error where it triggers the exception
* it enables optimizations like 7.1 got a lot
* it even may help a future JIT to optimize

due change every code i wrote to strict-types and enhance every function 
to type-hints and return types i found a ton of hidden probably bugs and 
especially fuzzying points out code weakness

> The logical syntax for that would probably be an explicit type in the 
> switch statement somewhere, like this:
> 
> switch(int $a)
> {
>   case 1: ..; break;
>   case 2: ..; break;
> }

i like that!

> Although an obvious question would be why switch gets such a version, 
> and what other language constructs should follow suit.

well, you have to start somewhere and the start was done with 7.0 for 
function params and return types, switch is an obvious  place that could 
be enhanced and the syntax above is 100% consistent to function params

it's not only consistent in the syntax, it's also consistent in behavior 
meaning in no-strict-mode make a implicit type cast and it's not a new 
syntax element

currently i have no other language constrcuts in mind but i think 
starting here could lead in people point out other places where it makes 
sense and since it's completly opt-in it don't break any existing code

ok, i have one in mind
foreach($arr as int $x)

raise a runtime error when you expect a array with only numbers and the 
comes '42' and in strict-mode do a consistent implicit cast in 
non-strict where you can be sure in both cases that you deal with a int 
within the loop