[PHP-DEV] PHP 7.4.0alpha2 is available for testing

PHP 7.4.0alpha2 has just been released and can be downloaded from: Or use the git tag: php-7.4.0alpha2 Windows binaries are available at: Please test it carefully, and report any bugs in the bug system. 7.4.0alpha3 should

Re: [PHP-DEV] [RFC] Strict operators directive

Hi Dik, Thanks for taking the time to review this RFC. On Wed, Jun 26, 2019 at 10:44 PM Dik Takken wrote: > Hello, > > Thanks a lot for your work on this RFC, it looks like a nice way to > allow the language to gradually move forward. > > As pointed out by others, the ==, ===, != and !==

Re: [PHP-DEV] [RFC] Strict operators directive

On Wed, Jun 26, 2019 at 1:46 PM Benjamin Morel wrote: > > * in some strict mode, reserve `<`, `==` etc. for numeric comparison, and > throw a TypeError one of the operand is not numeric; > > > * If we deem it worth, define a new operators for string comparison. > (Although I’m not really sure it

Re: [PHP-DEV] [RFC] Strict operators directive

Hello, Thanks a lot for your work on this RFC, it looks like a nice way to allow the language to gradually move forward. As pointed out by others, the ==, ===, != and !== operators are a bit problematic. A possible solution could be to leave them out of the RFC. The reason to do so is that the

Re: [PHP-DEV] [RFC] Strict operators directive

On Wed, Jun 26, 2019 at 12:39 PM Claude Pache wrote: > > > > Le 26 juin 2019 à 11:36, Benjamin Morel a > écrit : > > > >> (...) could be the case depending on a declaration somewhere else in the > > source code. > >> That's the confusion Claude and I were talking about: You cannot be sure > >

Re: [PHP-DEV] [RFC] Strict operators directive

On Wed, Jun 26, 2019 at 1:18 PM Alain D D Williams wrote: > On Wed, Jun 26, 2019 at 12:00:18PM +0100, Rowan Collins wrote: > > > Perl is a notable contrast: the types of operands are deduced based on > the > > operator, but there are different operators to force them to different > > types. So

Re: [PHP-DEV] [RFC] Strict operators directive

> > Given that we already have === and !==, could the strict mode simply throw > an error for *any* use of the non-strict == and != versions? > declare(strict_operators=1); > var_dump( "11" == "11.0" ); # TypeError: "Cannot use non-strict equality > operator in strict operator mode." > var_dump(

Re: [PHP-DEV] [RFC] Strict operators directive

On Wed, 26 Jun 2019 at 12:46, Benjamin Morel wrote: > This makes sense for "<", "<=", ">", ">=", but what about "==" and "!="? > > Currently, "11" == "11.0"; what would this yield under the new proposal? > > - leave it as is: return true in this case => contradicts the whole purpose > of the new

Re: [PHP-DEV] [RFC] Strict operators directive

> * in some strict mode, reserve `<`, `==` etc. for numeric comparison, and throw a TypeError one of the operand is not numeric; > * If we deem it worth, define a new operators for string comparison. (Although I’m not really sure it is worth: we have `strcmp()` and `===` for byte-to-byte

Re: [PHP-DEV] [RFC] Strict operators directive

On Wed, Jun 26, 2019 at 12:00:18PM +0100, Rowan Collins wrote: > Perl is a notable contrast: the types of operands are deduced based on the > operator, but there are different operators to force them to different > types. So `23 < 4` and `"23" < "4"` are both numeric comparisons, so return >

Re: [PHP-DEV] [RFC] Strict operators directive

On Wed, 26 Jun 2019 at 10:36, Benjamin Morel wrote: > Oh, I see. You mean that only replacing some of the current results with > TypeErrors would be acceptable; returning a different value would not. > This makes a lot of sense, but once again prevents the language from slowly > moving towards

Re: [PHP-DEV] [RFC] Strict operators directive

> Le 26 juin 2019 à 11:36, Benjamin Morel a écrit : > >> (...) could be the case depending on a declaration somewhere else in the > source code. >> That's the confusion Claude and I were talking about: You cannot be sure > what a very simple line of code does. > > Oh, I see. You mean that

Re: [PHP-DEV] [RFC] Strict operators directive

> (...) could be the case depending on a declaration somewhere else in the source code. > That's the confusion Claude and I were talking about: You cannot be sure what a very simple line of code does. Oh, I see. You mean that only replacing some of the current results with TypeErrors would be

Re: [PHP-DEV] [RFC] Strict operators directive

Am 26.06.2019 um 11:09 schrieb Benjamin Morel : > >> "120" > "99.9"; // TypeError >> Anything else will bring confusion. > > Not sure about this, you can do it the JS way: if both operands are > strings, then it behaves like strcmp(): > > "23" > "4"; // false > "23" > "221"; // true > > I'm

Re: [PHP-DEV] Re: Checkout phpdoc

> There is a small team of people currently working on moving the docs to git. > Due to the tight integration of SVN into the workflow it's not as easy as we all thought to do the actual move. > For more infos feel free to head over to https://github.com/phpdoctest/meta Thanks for the link! This

Re: [PHP-DEV] [RFC] Strict operators directive

>"120" > "99.9"; // TypeError > Anything else will bring confusion. Not sure about this, you can do it the JS way: if both operands are strings, then it behaves like strcmp(): "23" > "4"; // false "23" > "221"; // true I'm not saying that we should do it, but this would not be confusing to

Re: [PHP-DEV] [RFC] Strict operators directive

> Le 26 juin 2019 à 08:50, Christian Schneider a écrit : > > Am 25.06.2019 um 15:09 schrieb Arnold Daniels : >> This RFC proposes a new directive 'strict_operators'. When enabled, >> operators may cast operands to the expected type, but must comply to; >> >> * Typecasting is not based on

Re: [PHP-DEV] [RFC] Strict operators directive

Fixed the formatting. Sorry about that. :-s I really want to have a discussion prior to creating, to make sure there is consensus on what should be implemented. However, I will create a patch prior to voting. The implementation I have in mind is; 1. add a flag to `CG(active_op_array)->fn_flags`

Re: [PHP-DEV] [RFC] Strict operators directive

Am 25.06.2019 um 15:09 schrieb Arnold Daniels : > This RFC proposes a new directive 'strict_operators'. When enabled, operators > may cast operands to the expected type, but must comply to; > > * Typecasting is not based on the type of the other operand > > * Typecasting is not based on the