[PHP-DEV] Stricter implicit boolean coercions

[Andreas Leathley]

Hello Internals,

Implicit type coercions (when not using strict_types) have become
increasingly less lossy/surprising in PHP, especially coercions to
integer and float, where you get a TypeError if you pass a non-numeric
string to an integer parameter, and a deprecation notice if you pass a
float(-string) with a fractional part to an integer parameter. The big
exception so far is coercions to boolean, where you can provide any
scalar value and never get an error or a notice.

Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true. From my perspective this can
easily lead to hidden bugs, for example when passing the wrong variable
to a boolean argument or boolean property. Passing a string like "hello"
as a boolean is probably a bug, just like passing the number 854 or the
float 0.1 . "on" and "off" and "true" and "false" all lead to a boolean
true, as examples of strings that could be used in applications and
might not all be meant as a value of true.

I have not found any past proposals or discussions to change boolean
coercions, so I would like to find out how the thoughts on internals are
to change this, or if there are any reasons not to change this that I
have not thought of. Only allowing the following values would make sense
from my perspective:

'1' => true
1 => true
1.0 => true
'' => false
'0' => false
0 => false
0.0 => false

I can also see a case for allowing the strings 'true' and 'false', and
changing 'false' to be coerced to false, but that would be a BC break. I
am not sure if that is worthwhile.

Anything else would emit either a notice or a warning as a first step
(to be determined). My main goal would be to make these
probably-not-boolean usages more visible in codebases. Depending on the
feedback here I would create an RFC and try to do an implementation (to
then discuss it in more detail), so as of now this is mostly about
getting some basic feedback on such a change, and if someone else has
had any similar thoughts/plans.

Thanks for any feedback!

Andreas Leathley

[PHP-DEV] Re: Stricter implicit boolean coercions

[Mark Randall]

On 26/04/2022 10:54, Andreas Leathley wrote:

Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true.


If we could get rid of "0" being false, that alone would be a huge 
benefit for the language in the long run.


I know why it exists, but I don't think it should. In fact it never 
should have existed in the first place.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Stricter implicit boolean coercions

[Andreas Leathley]

On 26.04.22 12:02, Mark Randall wrote:

On 26/04/2022 10:54, Andreas Leathley wrote:

Any non-empty string (except "0") is converted to true and any non-zero
integer or float is converted to true.


If we could get rid of "0" being false, that alone would be a huge
benefit for the language in the long run.

I know why it exists, but I don't think it should. In fact it never
should have existed in the first place.


For me, highlighting all the places where a possibly unintended
conversion to true is happening would make "0" a lot less bad. "0.0"
being silently true while "0" and 0.0 is false seems a bit awkward.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.2 Release Manager Selection

[Mark Randall]

On 25/04/2022 12:51, Christoph M. Becker wrote:

Please put your name forward here if you wish to be considered a
candidate.  An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases[2].



I could potentially be interested in helping out with this, but I do 
have a question about it, mainly, why hasn't most of this been automated 
at this point?


I was reading through the release process notes and am not seeing any 
obvious blocks on most of it that could not be accomplished via a 
suitable CI/CD pipeline.


Is it just a matter of someone having time available to do it?

The one thing which does make me ponder is would we need to assign a GPG 
key to the build process?


I'd be happy to give some of my time later this year to further 
investigate this.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: PHP 8.2 Release Manager Selection

[Christoph M. Becker]

On 26.04.2022 at 12:31, Mark Randall wrote:

> On 25/04/2022 12:51, Christoph M. Becker wrote:
>
>> Please put your name forward here if you wish to be considered a
>> candidate.  An initial TODO page has been added to the wiki and contains
>> provisional dates for GA and pre-releases[2].
>
> I could potentially be interested in helping out with this, but I do
> have a question about it, mainly, why hasn't most of this been automated
> at this point?
>
> I was reading through the release process notes and am not seeing any
> obvious blocks on most of it that could not be accomplished via a
> suitable CI/CD pipeline.
>
> Is it just a matter of someone having time available to do it?
>
> The one thing which does make me ponder is would we need to assign a GPG
> key to the build process?
>
> I'd be happy to give some of my time later this year to further
> investigate this.

There are docker images available[1] which automate parts of the build
process.  However, doing the builds is only a rather small part of the
obligations of a release manager, and the other tasks (such as deciding
whether to merge a pull request, doing bug triage, and deciding on the
actual release schedule) cannot be automated.

[1] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: Add another php syntax for simplify code

[Christoph M. Becker]

On 26.04.2022 at 06:02, chopins xiao wrote:

> 0. when dot object opeator is enable, use small sign and add sign [<+]  be 
> equivalent to [.] for string concat mark.
>  compatibility is achieved through configuration switches.
>  syntax ：
>   >>> $a = 'str0';
>   >>> $a .= 'str1' <+ 'str2' <+ 'str3' <+ $str_var <+ strcall();
>   the concat equal sign[.=] not change
>
> 1. use dot mark[.] same with [->]
>  syntax:
>   >>> $a = new stdClass;
>   >>> $a.b  =1;   same with $a->b = 1  when dot object opeator is 
> enable in php.ini
>   >>> $a.get();same with $a->get()  when dot object opeator is 
> enable in php.ini
>
> 2. colon [:] same with [=>] in array declaration statement
>  syntax:
>   >>> $a = [ 'b' : 1, 'c' : 3 ]; same with $a = ['b'=>1,  'c' => 3]
>
> 3. another class declaration statement,  cant not use [extends] and 
> [implement] keyword
>  syntax:
>   >>> class Objects(ParentClass): Interface1,Interface2 {}
>   same with
>   >>> class Objects extends ParentClass implement 
> Interface1,Interface2 {}
>
>  anonymous class
>  >>> $obj = new($arg1,$arg2) class(ParentClass) : implement 
> Interface1,Interface2 {}
>  same with
>  >>> $obj = new class($arg1,$arg2) extends ParentClass implement 
> Interface1,Interface2{}
>
> 5. another class method declaration statement,  omit [function] keyword is 
> allowable
>  syntax:
>   >>> public method_name($args) {}
>   same with
>   >>> public function method_name($args) {}
>
> 6. restriction public magic method synax sugar, omit [public][function] 
> keywords and duoble underline[__] is allowable, only __get()  __set() 
> __call() __callStatic() __toString()  __sleep()  __wakeup()  __serialize()  
> __unserialize() is availabled
>   syntax:
>   >>>  class A {
>   >>>   get() {
>   >>>}
>   >>>call() {
>   >>>}
>   >>>  }
>   same with:
>   >>>  class A {
>   >>>   public function __get() {
>   >>>   }
>   >>>public function __call() {
>   >>>}
>   >>>  }
>
> The implement and syntax see:
>  https://github.com/chopins/php-src/blob/fast_grammar/FastSyntax.md

In my opinion, it is generally a bad idea to support different syntax
based on an INI setting.  This easily leads to confusion for those
reading the code.

I don't see much point in these "simplifications" anyway, except maybe
for the shorter array literals.  Note though, that there has been RFC[1]
about a similar syntax, but that had been declined.

[1] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Stricter implicit boolean coercions

[Christian Schneider]

Am 26.04.2022 um 11:54 schrieb Andreas Leathley :
> I have not found any past proposals or discussions to change boolean
> coercions, so I would like to find out how the thoughts on internals are
> to change this, or if there are any reasons not to change this that I
> have not thought of.

There are two big reasons:
- BC: Checking for the truthiness of a value is very common and would require a 
lot of code changes.
- Some of us like the conciseness of "if ($foo) ...", see below

> I can also see a case for allowing the strings 'true' and 'false', and
> changing 'false' to be coerced to false, but that would be a BC break. I
> am not sure if that is worthwhile.

I'm definitely against adding more special cases like 'false'.
Side-note: Removing something like '0' => false is also a BC break, not just 
adding 'false'.

> Anything else would emit either a notice or a warning as a first step
> (to be determined). My main goal would be to make these
> probably-not-boolean usages more visible in codebases. Depending on the
> feedback here I would create an RFC and try to do an implementation (to
> then discuss it in more detail), so as of now this is mostly about
> getting some basic feedback on such a change, and if someone else has
> had any similar thoughts/plans.


One of the big issues I have with this (as well as undefined variables not 
being allowed in if ($foo)) is that the replacement constructs are clunky:
if ($foo)  =>. if (!empty($foo))

For me this is quite a regression in readability but then again that's a matter 
of taste.
And would !empty($foo) even work in your world or how would empty() be defined?

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Stricter implicit boolean coercions

[Andreas Leathley]

On 26.04.22 14:47, Christian Schneider wrote:

There are two big reasons:
- BC: Checking for the truthiness of a value is very common and would require a 
lot of code changes.
- Some of us like the conciseness of "if ($foo) ...", see below


That would not be my target - in an if expression a lot more values are
allowed anyway (arrays, objects, etc.), so this is not about determining
truthiness, but actual conversions to a bool type, like a bool
parameter, a bool return type or a bool property type. The inspiration
for this is the "Deprecate implicit non-integer compatible float to int
conversions" (https://wiki.php.net/rfc/implicit-float-int-deprecate),
minus the mathematical expressions that were considered there. It is
about avoiding probably-unintended values being coerced to boolean and
therefore losing information / adding unnoticed bugs to a codebase.


I'm definitely against adding more special cases like 'false'.
Side-note: Removing something like '0' => false is also a BC break, not just 
adding 'false'.


I am not suggesting removing the coercion from the string '0' to false
or changing anything about that.


One of the big issues I have with this (as well as undefined variables
not being allowed in if ($foo)) is that the replacement constructs are
clunky:
if ($foo)  =>. if (!empty($foo))

For me this is quite a regression in readability but then again that's a matter 
of taste.
And would !empty($foo) even work in your world or how would empty() be defined?

empty is also not something I would consider covering, as there you also
do not need a conversion to a bool type.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Stricter implicit boolean coercions

[Rowan Tommins]

Am 26.04.2022 um 11:54 schrieb Andreas Leathley:


I have not found any past proposals or discussions to change boolean
coercions, so I would like to find out how the thoughts on internals are
to change this, or if there are any reasons not to change this that I
have not thought of.



I was actually thinking about this the other day, in the context of 
adding new cast functions which reject more values than our current 
explicit casts.


For integers, I can think of several levels of casts / type checks that 
you could theoretically define:


0) Plain type checking, no cast or coercion
1) Non-lossy casts, e.g. (string)(int)'42' === '42'
2) Unambiguous casts, e.g. (int)'42.0', (int)' 42 '
3) Best-guess casts, e.g. (int)'99 red balloons' === 99, (int)'1e3' === 1000
4) Zero failures, e.g. (int)'hello' === 0

When I started thinking about booleans, it was much harder to define 
what makes sense. I've certainly seen new programmers confused that 
(bool)'false' is true, and having it error would usually be more 
helpful; but (bool)'on' being true is useful when dealing with HTML 
forms, for instance.



On 26/04/2022 13:47, Christian Schneider wrote:

And would !empty($foo) even work in your world or how would empty() be defined?



That's an interesting question; but I think it would be OK for empty() 
to match with an *explicit* boolean cast, and both continue to accept 
all values, while *implicit* casts become more strict. This is how 
integers already work - (int)'hello' === 0, but passing 'hello' to an 
int parameter is an error regardless of mode, as is 'hello' + 1


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Stricter implicit boolean coercions

[Andreas Leathley]

On 26.04.22 15:27, Rowan Tommins wrote:


I was actually thinking about this the other day, in the context of
adding new cast functions which reject more values than our current
explicit casts.


This is also something I am interested in - having functions which do
the same as implicit type casts, so something like
"coerce_to_int('hello')" would lead to a TypeError like it would when
passing it to an int parameter, and maybe
"is_coerceable_to_int('hello')" which would return false, so it would be
possible to check values the same way as PHP does internally. The
current explicit cast functions are quite heavy-handed and not great for
every situation - when parsing a CSV or getting data from a database I
would rather coerce values where an error could occur if it doesn't make
sense than to explicitely cast and not even notice if the value made no
sense at all.


When I started thinking about booleans, it was much harder to define
what makes sense. I've certainly seen new programmers confused that
(bool)'false' is true, and having it error would usually be more
helpful; but (bool)'on' being true is useful when dealing with HTML
forms, for instance.


'on' is only true by "accident" though, because it is a non-empty
string, not because of its meaning, and then it is likely that the value
'off' could also be added at some point - which also would be true. One
of the big reasons of starting this discussion is because of HTML forms,
as that is where people might add values and not know what that leads to
in PHP. At these application boundaries it would be helpful to get a
clear message what value was converted to true (but might have lost
information by doing that) and what other value to use which is
considered more clear.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Stricter implicit boolean coercions

[Rowan Tommins]

On 26/04/2022 14:53, Andreas Leathley wrote:

'on' is only true by "accident" though, because it is a non-empty
string, not because of its meaning, and then it is likely that the value
'off' could also be added at some point - which also would be true. 



The reason I gave that particular example is that it's the default 
submission value for an HTML checkbox when checked; if it's not checked, 
it has no value at all (not even an empty string), so in that particular 
context there is no corresponding "off".


I think it falls into the same category as something like '1e3' being 
considered numeric - occasionally useful, but probably not worth the 
potential confusion of a special case.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Stricter implicit boolean coercions

[Christian Schneider]

Am 26.04.2022 um 15:16 schrieb Andreas Leathley :
> On 26.04.22 14:47, Christian Schneider wrote:
>> There are two big reasons:
>> - BC: Checking for the truthiness of a value is very common and would 
>> require a lot of code changes.
>> - Some of us like the conciseness of "if ($foo) ...", see below
> 
> That would not be my target - in an if expression a lot more values are
> allowed anyway (arrays, objects, etc.), so this is not about determining
> truthiness, but actual conversions to a bool type, like a bool
> parameter, a bool return type or a bool property type.

I see, so as long as there are no bool type hints for function parameters 
everything would be the same.

This would lead to a minor asymmetry for
$preserve = "yes";
if ($preserve)  # Silently working, true
array_slice($array, $offset, preserve_keys: $preserve));
# Not working any more

I assume your solution would be to add an explicit cast to bool? i.e. something 
along the lines of
array_slice($array, $offset, preserve_keys: (bool)$preserve));  
# Explicit cast to silence implicit conversion

I'm a bit worried about having to keep two different convert-to-bool rule sets 
in mind (implicit vs. explicit) and about the additional casts.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Aaron Junker]

Hi Internals

I have some interest in doing this. I think I know PHP and git very well and I 
also know more or less how the PHP internal processes work. However I have two 
doubts/questions:

1. How much time do I need for this task? I can't really estimate this. I sure 
have would have some time to spare, but definitely not too much.

2. I don't really know C. The mail says you don't necessarily have to. I could 
learn it if necessary though. So how bad would it be if I couldn't program in 
or understand C?

It would be nice if someone could answer them. Thanks!

Best regards
Aaron Junker



From: Christoph M. Becker 
Sent: Monday, 25 April 2022, 12:52
To: PHP internals 
Subject: [PHP-DEV] PHP 8.2 Release Manager Selection

Hi all,

with the first alpha of PHP 8.2 due in 6 weeks (unless we are going to
change our usual schedule), I think it's time to start the process of
finding and electing release managers for the next minor release of PHP.

We are looking for two souls to take on this role.  Whomsoever is
elected will be guided and helped by the current, as well as previous
RMs and the excellent documentation in release-process.md[1].

Candidates should have a reasonable knowledge of internals (without
necessarily being a C guru), be confident about merging pull requests
without breaking backward compatibility, doing triage for bugs,
liaising with previous release managers, and generally getting the
branch in good shape, as these are among the activities you will be
undertaking as release manager.

Notably, at least one of the volunteers must be a "veteran" release
manager meaning they have participated in at least one release of PHP in
the past.  The other may be an additional veteran, or more ideally,
someone new to the RM role (in order to increase our supply of veteran RMs).

Please put your name forward here if you wish to be considered a
candidate.  An initial TODO page has been added to the wiki and contains
provisional dates for GA and pre-releases[2].

[1] 
[2] 

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Evan Sims via internals]

Hello! I'd be eager for the opportunity to be involved as a release
manager, and contributing to the PHP community I've made built my career
around.

I've been a PHP developer since 2000 (with the release of PHP4), and
although I do not work in C in my day to day anymore, I cut my
programmer teeth on the language and worked with it quite extensively
previously. Today I'm the lead PHP engineer for Auth0 (now an Okta
product group) in charge of our PHP SDKs. I previously worked for the
non-profit Ushahidi has a Senior Engineer on their PHP-based platforms.
Beyond this, and aside from my time as a technical video gamer designer,
most of my freelance professional career has been around building PHP-
based apps.

Naturally, I live in Git these days with my work, triaging bugs. I'm a
strong communicator and enjoy collaborating and engaging with the open-
source community.

Cheers,
Evan Sims

On April 25, 2022, "Christoph M. Becker"  wrote:
> Hi all,
>
> with the first alpha of PHP 8.2 due in 6 weeks (unless we are going to
> change our usual schedule), I think it's time to start the process of
> finding and electing release managers for the next minor release of
> PHP.
>
> We are looking for two souls to take on this role. Whomsoever is
> elected will be guided and helped by the current, as well as previous
> RMs and the excellent documentation in release-process.md[1].
>
> Candidates should have a reasonable knowledge of internals (without
> necessarily being a C guru), be confident about merging pull requests
> without breaking backward compatibility, doing triage for bugs,
> liaising with previous release managers, and generally getting the
> branch in good shape, as these are among the activities you will be
> undertaking as release manager.
>
> Notably, at least one of the volunteers must be a "veteran" release
> manager meaning they have participated in at least one release of PHP
> in
> the past. The other may be an additional veteran, or more ideally,
> someone new to the RM role (in order to increase our supply of veteran
> RMs).
>
> Please put your name forward here if you wish to be considered a
> candidate. An initial TODO page has been added to the wiki and
> contains
> provisional dates for GA and pre-releases[2].
>
> [1]  process.md>
> [2] 
>
> --
> Christoph M. Becker
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Christoph M. Becker]

On 26.04.2022 at 17:21, Aaron Junker wrote:

> I have some interest in doing this. I think I know PHP and git very well and 
> I also know more or less how the PHP internal processes work. However I have 
> two doubts/questions:
>
> 1. How much time do I need for this task? I can't really estimate this. I 
> sure have would have some time to spare, but definitely not too much.

That very much depends.  Doing the releases (every 2 weeks) may take an
hour or so (or much less if you're using some automation).  The other
tasks may easily take more time, especially until the first GA release.
 Note, though, that there is a second RM, so the work can be distributed.

> 2. I don't really know C. The mail says you don't necessarily have to. I 
> could learn it if necessary though. So how bad would it be if I couldn't 
> program in or understand C?

As release manager, there is no need to *program* in C, but you should
have at least a working understanding of C to be able to roughly assess
PRs and commits, and to be able to resolve merge conflicts, if these occur.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Aaron Junker]

Hi internals

After answering my questions (Thanks Christoph) I would like to pose my 
application as release manager.

I'm a 17 year old college student from Switzerland.

I've experience in triaging issues and GitHub from triaging the Microsoft 
PowerToys repository [1][2] and the opensource.microsoft.com repository [3][4]. 
My GitHub handle is aaron-junker [5].

I'm very passionate about PHP and I love programming in PHP. That's why I would 
feel very honored to be a release manager for PHP 8.2.

I will soon start to learn the basics of C. That's something I wanted to learn 
anyway.

I would love to get taken in cosideration for this role.

Best regards

Aaron Junker

--

[1] https://github.com/microsoft/PowerToys
[2] 
https://github.com/microsoft/PowerToys/blob/main/COMMUNITY.md#aaron-junker---aaron-junker
[3] https://github.com/microsoft/opensource.microsoft.com
[4] 
https://github.com/microsoft/opensource.microsoft.com/blob/main/CONTRIBUTING.md?plain=1#L32
[5] https://github.com/Aaron-Junker

Re: [PHP-DEV] NULL Coercion Consistency

[Guilliam Xavier]

On Tue, Apr 26, 2022 at 12:18 AM Larry Garfield 
wrote:

> On Mon, Apr 25, 2022, at 4:07 PM, Rowan Tommins wrote:
>
> > Off the top of my head, I don't know what other inconsistencies remain,
> > but my point was that in every case so far, internal functions have been
> > adapted to match userland, not vice versa.
>
> 
>
> Internal functions error if you pass excessive arguments to a non-variadic
> function.  User-space functions just ignore the extras.  This is an
> inconsistency that has caused me considerable grief in the past year.
>
> I know Joe has said he wants userspace to become more strict like internal
> on this one.  I will not predict what actually happens.
>
> 
>



A few internal functions have parameters with an `UNKNOWN` default value in
the stubs, e.g.
https://github.com/php/php-src/blob/php-8.1.5/Zend/zend_builtin_functions.stub.php#L35

 function get_class(object $object = UNKNOWN): string {}

documented with a question mark at
https://www.php.net/manual/en/function.get-class.php

get_class(object $object = ?): string

or
https://github.com/php/php-src/blob/php-8.1.5/ext/standard/basic_functions.stub.php#L1558

function mt_rand(int $min = UNKNOWN, int $max = UNKNOWN): int {}

documented with two signatures at
https://www.php.net/manual/en/function.mt-rand.php

mt_rand(): int
mt_rand(int $min, int $max): int



-- 
Guilliam Xavier

Re: [PHP-DEV] Stricter implicit boolean coercions

[Alexandru Pătrănescu]

On Tue, Apr 26, 2022 at 12:54 PM Andreas Leathley 
wrote:

> Hello Internals,
>
> Implicit type coercions (when not using strict_types) have become
> increasingly less lossy/surprising in PHP, especially coercions to
> integer and float, where you get a TypeError if you pass a non-numeric
> string to an integer parameter, and a deprecation notice if you pass a
> float(-string) with a fractional part to an integer parameter. The big
> exception so far is coercions to boolean, where you can provide any
> scalar value and never get an error or a notice.
>
> Any non-empty string (except "0") is converted to true and any non-zero
> integer or float is converted to true. From my perspective this can
> easily lead to hidden bugs, for example when passing the wrong variable
> to a boolean argument or boolean property. Passing a string like "hello"
> as a boolean is probably a bug, just like passing the number 854 or the
> float 0.1 . "on" and "off" and "true" and "false" all lead to a boolean
> true, as examples of strings that could be used in applications and
> might not all be meant as a value of true.
>
> I have not found any past proposals or discussions to change boolean
> coercions, so I would like to find out how the thoughts on internals are
> to change this, or if there are any reasons not to change this that I
> have not thought of. Only allowing the following values would make sense
> from my perspective:
>
> '1' => true
> 1 => true
> 1.0 => true
> '' => false
> '0' => false
> 0 => false
> 0.0 => false
>
> I can also see a case for allowing the strings 'true' and 'false', and
> changing 'false' to be coerced to false, but that would be a BC break. I
> am not sure if that is worthwhile.
>
> Anything else would emit either a notice or a warning as a first step
> (to be determined). My main goal would be to make these
> probably-not-boolean usages more visible in codebases. Depending on the
> feedback here I would create an RFC and try to do an implementation (to
> then discuss it in more detail), so as of now this is mostly about
> getting some basic feedback on such a change, and if someone else has
> had any similar thoughts/plans.
>

I thought about coercion on parameters, return value and property types a
few weeks ago as well, both to and from bool:
In my opinion, only int should be coerced:
- bool to int: false to 0 and true to 1
- int to bool: 0 to false and anything else to true
That's because sometimes boolean values are stored numerically as 0 or 1.

What can be coerced but it might be good to remove as well:
- int numeric string to bool: '0' to false and anything else to true,
validity of a int numeric string, being considered the same as when
coercing string to int (empty string is not valid).

What should not be coerced:
- bool to string: false to '' and true to '1'
- string to bool: '' to false and anything else to true
- bool to float: false to 0.0 and true to 1.0
- float to bool: 0.0 to false and anything else to true
To me, all of these look like possible bugs and an explicit conversion
should be used if correctly intended.

Other types already raise errors to and from bool:
null|object|resource|array.

In terms of RFC, it would be pretty controversial as there's a lot of BC
breaks.
"bool to string" and "bool to float" are probably the most clear cases.

I have no plans to initiate a RFC in the near future, just sharing my
thoughts about it mostly.

Regards,
Alex

Re: [PHP-DEV] Stricter implicit boolean coercions

[Mel Dafert]

>I see, so as long as there are no bool type hints for function parameters 
>everything would be the same.
>
>This would lead to a minor asymmetry for
>   $preserve = "yes";
>   if ($preserve)  # Silently working, true
>   array_slice($array, $offset, preserve_keys: $preserve));
> # Not working any more
>
>I assume your solution would be to add an explicit cast to bool? i.e. 
>something along the lines of
>   array_slice($array, $offset, preserve_keys: (bool)$preserve));  
> # Explicit cast to silence implicit conversion
>
>I'm a bit worried about having to keep two different convert-to-bool rule sets 
>in mind (implicit vs. explicit) and about the additional casts.

There are already two different convert-to-bool rule sets for
array|object|resource|null, where they will be accepted in `if` but rejected 
when
passed to a function taking a bool param:

```
$x = (object) ['a'=> 1];

if ($x) {
  echo "if\n";
}

function takes_bool(bool $param) {}

takes_bool($x); // throws TypeError
```

https://3v4l.org/fCQFL

Adding string|float to that list doesn't seem to be that big of a difference 
here.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Calvin Buckley]

On Mon, 2022-04-25 at 13:51 +0200, Christoph M. Becker wrote:
> 
> Please put your name forward here if you wish to be considered a
> candidate.  An initial TODO page has been added to the wiki and
> contains
> provisional dates for GA and pre-releases[2].
> 

I'll put my name in the hat for applying to be an RM. I actually
package PHP as a downstream (for IBM i users), have tried to do what I
can for triaging issues (usually on behalf of my clients), and have
written some PRs for upstream. The skills there should be able to
inform the process as an RM, if I become one. I see some other good
candidates though, so I think 8.2 will be in good hands regardless.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PHP 8.2 Release Manager Selection

[Sergey Panteleev]

Hey Christoph,

Do we choose one rookie for this release or two (as for 8.1)?

Also, maybe define some kind of deadline for submitting applications and the 
voting phase, thoughts?

—
wbr,
Sergey Panteleev

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Eric Mann via internals]

I'm new to this mailing list as I'd previously (and very mistakenly) 
assumed it was meant for existing contributors. So I've always consumed 
conversations via web-based aggregators rather than directly.


My mistake.

That being said, I am very interested in being a part of this release. 
I've been using PHP since ~2005 and cut my teeth on PHP4. Since then, 
I've covered everything from Fortran to VB.net and C# to Ruby to Python 
to Golang. Today I write a mix of Python and PHP primarily (with a 
smattering of Go and a curiosity about Rust). I'm not a C guru, but in 
previous roles worked with several of them and can follow my way around 
a C codebase. I've frequently gone spelunking through PHP's system to 
help document various methods or interfaces exposed by the standard 
library as well.


I am in no way a veteran PHP RM, but I am a fairly experienced RM with 
private codebases. I live and breathe in Git, love automation, and have 
been accused of more than a passing fancy in security as well. Somewhere 
along the line I managed to coax php[architect] into publishing my book 
on the OWASP Top Ten, and they still put up with my monthly security 
column as well.


In other words, I'd love to be a part of this and am more than happy to 
answer any and all questions y'all want to throw my way.


~Eric Mann

On 4/26/22 11:27 PM, Sergey Panteleev wrote:

From: *Sergey Panteleev* 
Date: Tue, Apr 26, 2022 at 11:27 AM
Subject: [PHP-DEV] PHP 8.2 Release Manager Selection
To: Christoph M. Becker , PHP internals 




Hey Christoph,

Do we choose one rookie for this release or two (as for 8.1)?

Also, maybe define some kind of deadline for submitting applications 
and the voting phase, thoughts?


—
wbr,
Sergey Panteleev


--
Security Principles for PHP Applications 


*Eric Mann
* Tekton
*PGP:*0x63F15A9B715376CA 
*P:*503.925.6266
*E:*e...@eamann.com
eamann.com 
ttmm.io 
Twitter icon  LinkedIn icon 

Re: [PHP-DEV] Stricter implicit boolean coercions

[Rowan Tommins]

On 26/04/2022 14:53, Andreas Leathley wrote:

This is also something I am interested in - having functions which do
the same as implicit type casts, so something like
"coerce_to_int('hello')" would lead to a TypeError like it would when
passing it to an int parameter, and maybe
"is_coerceable_to_int('hello')" which would return false, so it would be
possible to check values the same way as PHP does internally. The
current explicit cast functions are quite heavy-handed and not great for
every situation - when parsing a CSV or getting data from a database I
would rather coerce values where an error could occur if it doesn't make
sense than to explicitely cast and not even notice if the value made no
sense at all. 



Yep, that's pretty much exactly where I was going. My current thinking 
is to have at least one of (deliberately long straw man names):


type_coerce_or_return_default(string $type, mixed $value, mixed 
$default): mixed

type_coerce_or_throw_error(string $type, mixed $value): mixed
type_can_be_coerced(string $type, mixed $value): bool

Accepting the type as a string is ugly, but means we don't need three 
functions for every type, and can easily support nullable types, union 
types, etc. Crucially, no special syntax means it's possible to write 
polyfills that compile in old PHP versions.


For simple types, you can mostly get away with one function:

$float_or_error = type_coerce_or_return_null('float', $var) ?? throw new 
TypeError;

$is_valid = type_coerce_or_return_null('float', $var) !== null;

But that's no use when null is a valid return type, so you need a 
hand-picked default and a bunch of extra boilerplate:


if ( $nullable_float = type_coerce_or_return_default('?float', $var, 
false) === false ) { throw new TypeError; }


$is_valid = type_coerce_or_return_default('null|float|bool', $var, 
'invalid value') !== 'invalid value';



The main point I'm stuck on at the moment is exactly how strict these 
should be, since we already have more than one set of coercion rules for 
each type, as Mel Dafert pointed out elsewhere on this thread. On the 
one hand, they should probably match with at least some existing rules; 
on the other, it would be weird to introduce them then immediately 
deprecate some behaviour because we've decided to make the language 
stricter elsewhere.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] NULL Coercion Consistency

[Rowan Tommins]

On 26/04/2022 17:36, Guilliam Xavier wrote:

 function mt_rand(int $min = UNKNOWN, int $max = UNKNOWN): int {}

documented with two signatures at
https://www.php.net/manual/en/function.mt-rand.php

 mt_rand(): int
 mt_rand(int $min, int $max): int



This is actually a really pertinent example: you might expect 
mt_rand(null, null) to give the same behaviour as mt_rand(), but 
actually it will always return 0, because it silently coerces to 
mt_rand(0, 0). That's exactly the kind of unexpected behaviour type 
checking aims to protect against.


There used to be a lot more functions with pseudo-defaults like this, 
but a lot were made to accept null in PHP 8.0. e.g. 
mb_convert_encoding('foo', 'ASCII', null) now acts like 
mb_convert_encoding('foo', 'ASCII') and looks up a run-time default; but 
in previous versions it acted as mb_convert_encoding('foo', 'ASCII', '') 
which is not a valid call.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Joe Watkins]

Hi all,

Applications are open for a week.

Two people will be chosen by election and a veteran will help them.

If no other veteran comes forward I will continue in that role for 8.2.

Cheers
Joe

On Tue, 26 Apr 2022, 21:21 Eric Mann via internals, 
wrote:

> I'm new to this mailing list as I'd previously (and very mistakenly)
> assumed it was meant for existing contributors. So I've always consumed
> conversations via web-based aggregators rather than directly.
>
> My mistake.
>
> That being said, I am very interested in being a part of this release.
> I've been using PHP since ~2005 and cut my teeth on PHP4. Since then,
> I've covered everything from Fortran to VB.net and C# to Ruby to Python
> to Golang. Today I write a mix of Python and PHP primarily (with a
> smattering of Go and a curiosity about Rust). I'm not a C guru, but in
> previous roles worked with several of them and can follow my way around
> a C codebase. I've frequently gone spelunking through PHP's system to
> help document various methods or interfaces exposed by the standard
> library as well.
>
> I am in no way a veteran PHP RM, but I am a fairly experienced RM with
> private codebases. I live and breathe in Git, love automation, and have
> been accused of more than a passing fancy in security as well. Somewhere
> along the line I managed to coax php[architect] into publishing my book
> on the OWASP Top Ten, and they still put up with my monthly security
> column as well.
>
> In other words, I'd love to be a part of this and am more than happy to
> answer any and all questions y'all want to throw my way.
>
> ~Eric Mann
>
> On 4/26/22 11:27 PM, Sergey Panteleev wrote:
> > From: *Sergey Panteleev* 
> > Date: Tue, Apr 26, 2022 at 11:27 AM
> > Subject: [PHP-DEV] PHP 8.2 Release Manager Selection
> > To: Christoph M. Becker , PHP internals
> > 
> >
> >
> > Hey Christoph,
> >
> > Do we choose one rookie for this release or two (as for 8.1)?
> >
> > Also, maybe define some kind of deadline for submitting applications
> > and the voting phase, thoughts?
> >
> > —
> > wbr,
> > Sergey Panteleev
> >
> --
> Security Principles for PHP Applications
> 
> *Eric Mann
> * Tekton
> *PGP:*0x63F15A9B715376CA 
> *P:*503.925.6266
> *E:*e...@eamann.com
> eamann.com 
> ttmm.io 
> Twitter icon  LinkedIn icon
> 
>