I have amended the RFC on
https://wiki.php.net/rfc/stricter_implicit_boolean_coercions to address
the feedback I got so far, I also added an overview of scalar type
coercions to give a better sense of how these changes fit in with
current type coercion behavior, and I added a Future Scope section
On 24.05.22 15:33, Dan Ackroyd wrote:
"When discussion ends, and a minimum period of two weeks has passed"
Fyi, the two weeks is a minimum, and almost certainly not enough time
for subtle BC breaking RFCs like this.
I explicitely stated that to make it clear that this should be
considered a
>> In one application recently I actually had the string "false" (coming
>> from a form transmission) being passed to a boolean argument and leading
>> to true, which definitely was unintended.
>
>But "false" is a perfectly sensible thing to pass as a string in an
>API (as HTTP is a string based
On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote:
> I have created a preliminary
> implementation and an RFC for making implicit boolean type coercions
> more strict:
>
> https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
>
> With this email I'm starting the two week discussion
On 23.05.22 20:58, Juliette Reinders Folmer wrote:
All in all, I largely agree with the flaws in this proposal as
previously pointed out by Christian Schneider in the preliminary
discussion. And I don't see those concerns addressed in the RFC (other
than making it more explicit what the actual
On 23.05.22 22:54, G. P. B. wrote:
I don't like this RFC as it introduces special coercion semantics for
boolean *only* in a function (+ typed properties (well at least I hope it
impacts typed properties)) context.
The obvious other context is the logical one with conditional statements
and/or
On Mon, 16 May 2022 at 16:06, Andreas Leathley wrote:
> Hello Internals,
>
> After the first discussion about this topic
> (https://externals.io/message/117608) I have created a preliminary
> implementation and an RFC for making implicit boolean type coercions
> more strict:
>
>
On 23.05.22 20:58, Juliette Reinders Folmer wrote:
This RFC worries me as, in my opinion, it makes PHP's behaviour more
surprising and inconsistent, not less.
It also raises the cognitive complexity for developers by yet another
level.
1. It introduces a new interpretation of boolean type
On 23 May 2022, at 19:58, Juliette Reinders Folmer
wrote:
> I also fear that for code bases which do not (yet) use scalar type
> declarations, this will be one more argument not to introduce scalar type
> declarations (while they should).
>
> I'd say that for this RFC to be acceptable it
On 16-5-2022 17:06, Andreas Leathley wrote:
Hello Internals,
After the first discussion about this topic
(https://externals.io/message/117608) I have created a preliminary
implementation and an RFC for making implicit boolean type coercions
more strict:
On 17.05.22 11:18, Jordi Boggiano wrote:
Thanks for the RFC. I think it's overall a good idea, especially for
cases like "false" => true, and arguably for ints >1/<0, but my gut
feeling is the string=>bool deprecation will lead to a lot of pain.
I definitely see this being done in many places
On 16.05.22 18:24, Guilliam Xavier wrote:
Thanks! Am I right that it only affects *type declarations*, and the
"Unaffected PHP Functionality" section could also mention implicit
boolean evaluation in `if`, ternary conditional (?:) and logical
operators (!, &&, ||, and, or, xor)?
Yes, that is
On Mon, May 16, 2022 at 5:06 PM Andreas Leathley wrote:
>
> Hello Internals,
>
> After the first discussion about this topic
> (https://externals.io/message/117608) I have created a preliminary
> implementation and an RFC for making implicit boolean type coercions
> more strict:
>
>
On 16 May 2022, at 16:19, Kamil Tekiela wrote:
> On 16 May 2022, at 16:06, Andreas Leathley wrote:
>> https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
>
> Has any case study been done already about how it will affect existing
> codebases?
The last time this happened there were no
Hello Kamil,
I suspect this is very different depending on the codebase. My main
reason for introducing this deprecation notice is to start highlighting
possible problems in codebases where nobody even suspected them before.
In one application recently I actually had the string "false" (coming
Hi Andreas,
Has any case study been done already about how it will affect existing
codebases?
Regards,
Kamil
Hello Internals,
After the first discussion about this topic
(https://externals.io/message/117608) I have created a preliminary
implementation and an RFC for making implicit boolean type coercions
more strict:
https://wiki.php.net/rfc/stricter_implicit_boolean_coercions
With this email I'm
17 matches
Mail list logo
