On 26.04.22 16:36, Rowan Tommins wrote:
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.
> > '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
>
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
>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:
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
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
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
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
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
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
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
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
12 matches
Mail list logo
