Re: [PHP-DEV] The future of objects and operators

[MKS Archive]

> On May 6, 2022, at 6:16 PM, Jordan LeDoux  wrote:
> 
> Hello all,
> 
> I took a while away after my operator overload RFC was declined. I've been
> mulling for the last few months how to move forward while respecting the
> concerns and feedback of those who abstained and those who voted against.
> But I feel like a separate discussion needs to happen first after
> considering many different approaches.
> 
> # There is Considerable Demand For Improved Control of Operators with
> Objects
> 
> This doesn't apply to all operators. I have not seen any comments in the
> last few months of digging of people who are desperate for the pow operator
> ( ** ) for instance. However, many people who work with math in PHP have
> use for at least the arithmetic operators and I see this comment frequently.
> 
> Totally separate from the math domain, I've seen many comments about the
> desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This
> is something that would have numerous applications outside of mathematics,
> and there's even been an RFC worked on (that was declined in 2018) by Rudi
> to implement just comparisons.
> 
> # Different Voters Have Different Concerns
> 
> This is an issue that almost all RFC authors must deal with of course, but
> this particular subject suffers from it more severely than most. For
> instance, in some of the past proposals that were more limited than mine,
> there were comments that a full operator overloading solution should be
> provided instead of something halfway.
> 
> However one of the comments I received more than once was that I should
> separate out the comparison operators into its own RFC, since those have
> applications outside the math domain.
> 
> # Is Math A Valid Use Case?
> 
> One of the more shocking (to me personally) pieces of feedback that I
> received from more than one person is that math is not a valid use case in
> PHP. I am... unsure about what to think of this opinion. I guess I would
> like to discuss and find out if this is widely believed among voters.

I will repeat what I suggested back before the RFC was voted on, and that is 
you consider *starting* your campaign for operator overloads with an RFC to add 
a built-in Math class (or set of classes) to PHP, one(s) that can have all the 
operator overloading it/they need(s).

Minimally the design process in the open would be insightful for everyone 
interested in the topic even if the RFC did not get accepted — although the 
intent should be that it would — because it would change the operator overload 
discussion from a very abstract one to a very concrete one. 

It could also illustrate the benefit for operator overloading, and illustrate 
the design process of deciding on how operators are overloaded and what the 
benefits and tradeoffs are of different choices.

If the RFC did not pass, at least it could result in an understanding of which 
operators minimally need to be overloaded for the Math use-case and serve as a 
blueprint for adding Math objects in userland if and when sufficient 
general-purpose operator overloading could get added to PHP.

Further, if an RFC to add a built-in Math object to PHP passed it would 
effectively eliminate the red-herring of "I don't do heavy math work."  Such an 
RFC would also, of course, not have the other two (2) categories of objections 
that you named in your other email.

Again, #jmtcw

-Mike

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

Re: [PHP-DEV] NULL Coercion Consistency

[Jordan LeDoux]

On Sat, May 7, 2022 at 2:11 PM Jordan LeDoux 
wrote:

>
>  I'm concerned from your replies in this thread and the content of the RFC
> that you don't actually understand the extent of a BC-break you're
> proposing.
>
>
Sorry, that was a tad more combative than I intended. What I'm trying to
say is that I'm concerned there may be a blindspot here about the impact
which could significantly impact developers in ways that aren't being
accounted for.

Jordan

Re: [PHP-DEV] NULL Coercion Consistency

[Jordan LeDoux]

On Sat, May 7, 2022 at 1:38 AM Craig Francis 
wrote:

>
> Not what I'm going for... but anyway, to get an idea of your position, do
> you think the string '15' should be coerced to a number, or should it fatal
> error as well? e.g.
>
> $my_number = round($request->get('my_number'));
>
>
'15' is not an undefined value.

If a program uses the paradigm that null represents the equivalent of
something like `unset($var)`, then the program would not expect coercion to
happen at all if a specific type is demanded, for the same reason that a C
program wouldn't expect an out-of-range memory address to silently evaluate
as an int 0. For programs that use this paradigm, the type system that PHP
*already uses* which has a difference between `?int` and `int`, means that
there is an explicit piece of code noting the exceptions to this rule about
how null is treated.

What exactly would be the purpose of `?int` if this RFC was passed? To pass
the value as null instead of 0? That's it? What about `int|float`? Which
one would it be coerced to? This pretty radically changes how typing itself
would work in existing user programs. What I'm saying is that for such a
radical BC break you need to provide some compelling justification, and I'm
concerned from your replies in this thread and the content of the RFC that
you don't actually understand the extent of a BC-break you're proposing.

Jordan

Re: [PHP-DEV] The future of objects and operators

[Jordan LeDoux]

On Sat, May 7, 2022 at 11:40 AM Larry Garfield 
wrote:

>
> I would group object operators into 4 categories/levels.
>
> 1. Object-universal operators.  This would be support for operators that
> make sense in all domains.  Mainly this is the comparison operators but
> there may be others.
> 2. Arithmetic operators.  The 4 basic operations.  Maybe even just 3
> (excluding division as it's a bit more complex than the others
> conceptually).
> 3. Full operator overloading: If an operator exists, a class can override
> it, on principle, even if there's no obvious common use case.
> 4. Custom overloading: User-space can define additional operators for
> specific objects.
>
> Jordan's RFC was effectively level 3, with a syntax designed to be
> extensible to level 4 in the future if desired.  Naturally the line between
> these levels if a little bit fuzzy and there's some overlap.
>   ...

I frankly think this is a red herring; it's a "I don't do heavy math work
> in PHP, so arguing that feature X makes PHP better for math carries no
> weight."  It shouldn't be read as "PHP being good at complex computations
> is bad in itself."  (If anyone does actually believe that, I'd say speak up
> but I'd just tell you that you're wrong from the get-go, so maybe let's not
> pick that fight and leave it as a hypothetical. :-) )
> ...
> My recommendation would be to use the same syntax and model as before and
> just target object-universal operators, ie, comparisons.  (Level 1 from
> above.)  That gets the syntax in place, and lets us flush out the engine
> hook weirdness.  If we could get that to pass, it would at least get people
> comfortable with the idea and concept.  The higher level parts could then
> be an easier sell in the future in a version or two once people have gotten
> more used to the idea.
>
>
Of the people who did vote no and also provided me feedback, there were
*mainly* three reasons given (some in public such as on this list, and some
in private in more direct conversation):

1. Math is not a valid use case.
2. Operator overloading for objects is something I will vote against in any
context for any design, no matter the argument or evidence provided.
3. Operator overloading presents problems for static analysis and tooling
which are more significant than the benefits.

I could argue against all three positions, but as you noted, I don't think
argument or debate is really helpful right now. Instead I'd like to talk at
a more high level about what sort of long-term future PHP contributors and
voters see for objects when it comes to allowing developers to control
object behavior.

I like the way you organized the different levels of support within the
feature, it's a good organizational structure for thinking about the
feature-set. Given the feedback though, I found myself a little concerned
that if I created a Level 1 proposal, it's very possible that the people in
groups 1 and 3 above might vote for it. However, in doing so it's also very
possible that all the use-cases those voters care about would then be
covered, and many would then block anything which helps use-cases they do
not commonly use. In essence, the particular feedback I received made me
concerned that passing a Level 1 RFC would basically guarantee that Level
2+ would never happen until the voter base itself was significantly changed.

Even so... I think I agree with your suggestion at this point. At the very
least, even if my concern above was proven true, it would then at least be
*possible* for me to provide an extension for PHP which addresses some of
the shortcomings for math.

The main issue when it comes to comparisons is addressed in the PR I
linked, which basically boils down to "for objects, it makes sense for
equatable and comparable to be separated sometimes". Whether this involves
a fall-through in the VM for objects as done in my linked PR, or involves
new handlers for objects as CMB commented on that PR instead, it's actually
a very minor change technically within the engine to implement Level 1
support as you described it.

Jordan

Re: [PHP-DEV] Possible improvements to the Reflection functionality

[Ollie Read]

Hey again!
> Greetings.
> 
> I've also been doing a lot of work with Reflection lately as part of 
> https://github.com/Crell/AttributeUtils .  I agree with and support almost 
> all of these additions.  (I'm no entirely convinced by 
> getNumberOfAttributes(), but I don't really see a harm in it.)

Yeah, the idea behind getNumberOfAttributes was merely because it doesn't hurt 
to have, and since we're dealing with having 1 or more of a particular type of 
attribute, there are absolutely going to be times when has and get won't cut it.

> There was another short thread on the list back in February?, I think, about 
> some improvements to reflection.  We desperately need a few more well-placed 
> interfaces and stubs for things like attributes, and even getName().  My C-fu 
> is paltry if I'm being polite, but I'm happy to help with process and RFC 
> writing/documentation.  The Reflection API is badly in need of some love.

I'm super new to the list, in fact, this was my first interaction with it at 
all. My C-fu is practically non-existent, in fact, the first thing I ever did 
with C in my entire life, was the PR to fix the bug with closure attributes. 
That being said, I'm fairly confident that I have a decent understanding of how 
the reflection parts of the codebase work, and I've spent enough time poking 
around it that I think I know how to do most of what I have suggested.

> In practice, I think most of these would require RFCs.  The question is 
> whether they're better as a bunch of stand-alone RFCs or one big "clean up 
> Reflection" RFC or a series of "clustered" RFCs.  I'm not sure what's most 
> palatable to folks these days.

That's a good point. I'd be inclined to, at the very least, create two RFCs, 
one for types, and one for attributes, as while they both use reflection, 
they're very different points that are only connected in that they're part of 
reflection.

Since posting the original list, I even came up with an idea to expand on the 
typing, and introduce actual classes for each of the "types" (perhaps an enum), 
that the reflection types can use. I think that would be super useful for a lot 
of stuff, all the way from dependency injection to static analysis. Something 
like https://docs.microsoft.com/en-us/dotnet/api/system.type?view=net-6.0, but 
we could probably just make the reflection classes use that.

I'd also like to see the Reflection prefix dropped and proper namespacing 
introduced, but I also know that's not going to go down well with a lot of 
people.

Am happy to hear any suggestions or input, especially how people feel about the 
whole RFC side of things.

---
Best Regards,
*Ollie Read*

Re: [PHP-DEV] The future of objects and operators

[Larry Garfield]

On Fri, May 6, 2022, at 5:16 PM, Jordan LeDoux wrote:
> Hello all,
>
> I took a while away after my operator overload RFC was declined. I've been
> mulling for the last few months how to move forward while respecting the
> concerns and feedback of those who abstained and those who voted against.
> But I feel like a separate discussion needs to happen first after
> considering many different approaches.

Speaking only for myself, of course...

> # There is Considerable Demand For Improved Control of Operators with
> Objects
>
> This doesn't apply to all operators. I have not seen any comments in the
> last few months of digging of people who are desperate for the pow operator
> ( ** ) for instance. However, many people who work with math in PHP have
> use for at least the arithmetic operators and I see this comment frequently.
>
> Totally separate from the math domain, I've seen many comments about the
> desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This
> is something that would have numerous applications outside of mathematics,
> and there's even been an RFC worked on (that was declined in 2018) by Rudi
> to implement just comparisons.

I would group object operators into 4 categories/levels.

1. Object-universal operators.  This would be support for operators that make 
sense in all domains.  Mainly this is the comparison operators but there may be 
others.
2. Arithmetic operators.  The 4 basic operations.  Maybe even just 3 (excluding 
division as it's a bit more complex than the others conceptually).
3. Full operator overloading: If an operator exists, a class can override it, 
on principle, even if there's no obvious common use case.
4. Custom overloading: User-space can define additional operators for specific 
objects.

Jordan's RFC was effectively level 3, with a syntax designed to be extensible 
to level 4 in the future if desired.  Naturally the line between these levels 
if a little bit fuzzy and there's some overlap.

> # Different Voters Have Different Concerns
>
> This is an issue that almost all RFC authors must deal with of course, but
> this particular subject suffers from it more severely than most. For
> instance, in some of the past proposals that were more limited than mine,
> there were comments that a full operator overloading solution should be
> provided instead of something halfway.
>
> However one of the comments I received more than once was that I should
> separate out the comparison operators into its own RFC, since those have
> applications outside the math domain.

See above regarding "levels" of support.

> # Is Math A Valid Use Case?
>
> One of the more shocking (to me personally) pieces of feedback that I
> received from more than one person is that math is not a valid use case in
> PHP. I am... unsure about what to think of this opinion. I guess I would
> like to discuss and find out if this is widely believed among voters.

PHP is today rarely used for heavy-math use cases.  It's mostly 
line-of-business applications, aka "over-engineered ways of concatenating 
strings out of a database."  Historically it's been too slow for that, which 
lead to no community around it, so no one did it, so no focused improvements in 
that area, so...  Infinite loop.  Python got most of that attention instead.

However, the JIT and FFI work have quite frankly very little use *other than* 
computation intensive (ie, math) use cases, and those were added without issue 
despite having APIs that are extremely crappy. :-)   So I don't understand the 
"math doesn't matter" argument either; if it doesn't matter, we wouldn't have 
needed JIT or FFI either.

I frankly think this is a red herring; it's a "I don't do heavy math work in 
PHP, so arguing that feature X makes PHP better for math carries no weight."  
It shouldn't be read as "PHP being good at complex computations is bad in 
itself."  (If anyone does actually believe that, I'd say speak up but I'd just 
tell you that you're wrong from the get-go, so maybe let's not pick that fight 
and leave it as a hypothetical. :-) )

> # Non-Breaking Engine Changes
>
> The way that equality and comparison evaluation is done in the engine makes
> it impossible for certain kinds of overloading to be done, even in
> extensions. This isn't because that was an intended restriction, I
> discussed this issue with CMB and provided a PR a few months ago to resolve
> this, however it has remained in limbo:
> https://github.com/php/php-src/pull/7973
>
> # Overall Vision
>
> I'm not sure at this point how voters think objects and operators should
> work together into the future. I'd like to see if anyone is willing to have
> high-level discussion about the ideas, instead of picking at the
> implementation or details of a particular RFC.
>
> Jordan

I am always down for high-level ideas discussions. :-P

As even the detractors noted, the previous RFC is probably the best design that 
could be done, given PHP's existing nature.  So aside 

Re: [PHP-DEV] Possible improvements to the Reflection functionality

[Larry Garfield]

On Thu, May 5, 2022, at 12:04 PM, Ollie Read wrote:
> Hello all,
>
> I've been spending a lot of time in the world of PHP reflection lately, 
> which has led me to create PRs for the documentation, a bug for closure 
> attributes, and even a new method on ReflectionMethod. I've also 
> compiled a list of suggestions for various additions and improvements 
> to some parts of reflection. 
>
> You can find it here: 
> https://gist.github.com/ollieread/34c878bf120ee70f9d2a869cb7a242d1
>
> I'm looking for some feedback on the various elements and some 
> guidance, if any have merit, as to whether they're going to require any 
> sort of RFC. I'm also happy to create PRs for some of the features, if 
> not all, though I think there are definitely some beyond my current 
> knowledge. I would also be interested in hearing from anyone who also 
> has other suggestions that could be added to this.
>
> Apologies if I'm missing something, or I could have done something 
> better, this is my first interaction with this mailing list, so I am 
> also happy to receive any feedback about the best approaches and ways 
> to handle things, if necessary.

Greetings.

I've also been doing a lot of work with Reflection lately as part of 
https://github.com/Crell/AttributeUtils .  I agree with and support almost all 
of these additions.  (I'm no entirely convinced by getNumberOfAttributes(), but 
I don't really see a harm in it.)

There was another short thread on the list back in February?, I think, about 
some improvements to reflection.  We desperately need a few more well-placed 
interfaces and stubs for things like attributes, and even getName().  My C-fu 
is paltry if I'm being polite, but I'm happy to help with process and RFC 
writing/documentation.  The Reflection API is badly in need of some love.

In practice, I think most of these would require RFCs.  The question is whether 
they're better as a bunch of stand-alone RFCs or one big "clean up Reflection" 
RFC or a series of "clustered" RFCs.  I'm not sure what's most palatable to 
folks these days.

--Larry Garfield

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

Re: [PHP-DEV] NULL Coercion Consistency

[Aleksander Machniak]

On 07.05.2022 13:29, Mel Dafert wrote:

It is exactly user-defined functions that this RFC introduces breakage for.
The behaviour to throw on null in user-defined functions exists since PHP
7.0, and is being relied on. Changing these now would introduce behaviour 
changes
that are harder to find than new type errors.
Using strict typing isn't an option either/would be just as much work as 
auditing
the changes this would introduce.

It may be that user-defined functions should have accepted null to begin with in
your opinion, but that still makes it a breaking change now.



Indeed. I suggest to add a note to "Backward Incompatible Changes" 
section of the RFC. This changes the contract, but does not throw new 
errors in existing code.



Now my 2 cents, reading docs and RFCs (I'm not the internals developer):

The https://wiki.php.net/rfc/scalar_type_hints_v5 says that NULL was 
excluded "in order to be consistent with our existing type declarations 
for classes, callables and arrays".


So, to me it sounds like the main reason was that NULL can't be cast to 
array/object/callable, not that it was expected to be treated as a new 
type in the future, nor more strictness was intended.


At the time excluding NULL made sense as it was a new feature anyway, 
and it didn't apply to internal functions, so it was fully sign-in 
feature. Although I must say that "it should be possible for existing 
userland libraries to add scalar type declarations without breaking 
compatibility" wasn't really true, because of NULL.


You could call the proposed NULL-to-scalar coercion in weak-type checks 
a new feature that makes 
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg 
obsolete/invalid, still, there are good reasons to do this. Imo, the BC 
break is much less problematic than the one we're trying to solve here.


--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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

Re: [PHP-DEV] NULL Coercion Consistency

[Mel Dafert]

On 7 May 2022 12:54:45 CEST, Craig Francis  wrote:
>I will note that my RFC does not change NULL coercion (why I quoted the 
>documentation), and I'm not against the other BC breaks where certain type 
>coercions are clearly problematic.
>
>It was 8.1 which introduced this specific BC problem (with ignorable 
>deprecation notices)... and while that change was to begin alignment with user 
>defined functions, it's the user defined functions that have been the oddity 
>(i.e. do not use NULL coercion, unlike other contexts, such as concatenation, 
>== comparisons, arithmetics, sprintf, print, echo, array keys). Personally I 
>think it should have been user defined functions that worked with the "old and 
>well known" coercion rules, and doing so would have reduced complexity (i.e. 
>working in the same way).
...
>But my focus is on upgrading existing code, and this one is difficult to find 
>and update (e.g. the lack of tooling to help).

It is exactly user-defined functions that this RFC introduces breakage for.
The behaviour to throw on null in user-defined functions exists since PHP
7.0, and is being relied on. Changing these now would introduce behaviour 
changes
that are harder to find than new type errors.
Using strict typing isn't an option either/would be just as much work as 
auditing
the changes this would introduce.

It may be that user-defined functions should have accepted null to begin with in
your opinion, but that still makes it a breaking change now.

Regards, 
Mel

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

Re: [PHP-DEV] NULL Coercion Consistency

[Craig Francis]

> On 7 May 2022, at 10:01, Marco Pivetta  wrote:
> 
> Hey Craig 


Hi Marco,

Thanks for your thoughts.



> On Sat, 7 May 2022, 10:39 Craig Francis,  > wrote:
> Not what I'm going for... but anyway, to get an idea of your position, do you 
> think the string '15' should be coerced to a number, or should it fatal error 
> as well? e.g.
> 
> $my_number = round($request->get('my_number'));
> 
> Passing '15' for `int` should throw a type error: this is why people (slowly, 
> steadily) opt into strict types.


I don't think everyone agrees :-)



> I mostly refrained from commenting on this RFC thus far exactly because I'm 
> already "out of the woods", and I already add strict types everywhere.
> 
> Still, when upgrading legacy PHP apps, I would have to deal with the problem, 
> at which point I prefer looking for type errors in internal function calls, 
> than looking for changes in null coercion (the one proposed here) everywhere.
> 
> Practically, my idea is:
> 
>  * coercion rules are old and well known
>  * changing coercion rules around `null` drags in complexity
>  * focus should be in migrating to strict types instead
> 
> Regardless of the output of this RFC, people upgrading to 8.0 or 8.1 will 
> already experience BC breaks in internal function input types, and adapt to 
> them.


I will note that my RFC does not change NULL coercion (why I quoted the 
documentation), and I'm not against the other BC breaks where certain type 
coercions are clearly problematic.

It was 8.1 which introduced this specific BC problem (with ignorable 
deprecation notices)... and while that change was to begin alignment with user 
defined functions, it's the user defined functions that have been the oddity 
(i.e. do not use NULL coercion, unlike other contexts, such as concatenation, 
== comparisons, arithmetics, sprintf, print, echo, array keys). Personally I 
think it should have been user defined functions that worked with the "old and 
well known" coercion rules, and doing so would have reduced complexity (i.e. 
working in the same way).

I'm also not against increasing strictness, and some of the type errors (ref 
previous emails, and noted in my RFC), but I think it's more of a balance, 
where an overly strict environment creates different problems (e.g. making the 
language much more verbose, and can be unnecessarily hard to learn/use).

But my focus is on upgrading existing code, and this one is difficult to find 
and update (e.g. the lack of tooling to help).

Craig

Re: [PHP-DEV] NULL Coercion Consistency

[Marco Pivetta]

Hey Craig

On Sat, 7 May 2022, 10:39 Craig Francis,  wrote:

> Not what I'm going for... but anyway, to get an idea of your position, do
> you think the string '15' should be coerced to a number, or should it fatal
> error as well? e.g.
>
> $my_number = round($request->get('my_number'));
>

Passing '15' for `int` should throw a type error: this is why people
(slowly, steadily) opt into strict types.

I mostly refrained from commenting on this RFC thus far exactly because I'm
already "out of the woods", and I already add strict types everywhere.

Still, when upgrading legacy PHP apps, I would have to deal with the
problem, at which point I prefer looking for type errors in internal
function calls, than looking for changes in null coercion (the one proposed
here) everywhere.

Practically, my idea is:

 * coercion rules are old and well known
 * changing coercion rules around `null` drags in complexity
 * focus should be in migrating to strict types instead

Regardless of the output of this RFC, people upgrading to 8.0 or 8.1 will
already experience BC breaks in internal function input types, and adapt to
them.

This RFC added on top of that further destabilises the upgrade path to 8.2
or other versions (wherever introduced).

For me, this makes the RFC a net negative value for the language and its
consumers, as it adds a problem.

>

Re: [PHP-DEV] NULL Coercion Consistency

[Craig Francis]

On 7 May 2022, at 06:59, Aleksander Machniak  wrote:
> 
> On 08.04.2022 19:34, Craig Francis wrote:
>> Hi,
>> I've written a new draft RFC to address the NULL coercion problems:
>> https://wiki.php.net/rfc/null_coercion_consistency
> 
> As a voter, I'm in favor of this RFC.
> 
> I suggest to rename "Documentation" section title to "Scalars coercion 
> inconsistency" or sth like that, as this section isn't really much about the 
> documentation, rather the current state.


Good point Aleksander, I started with 5 quotes from the Documentation, but 
you're right, the examples have grown a bit since then, and the second part 
does show the Current State, so I've gone with that heading (hope that's ok).

Craig

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

Re: [PHP-DEV] NULL Coercion Consistency

[Craig Francis]

On 7 May 2022, at 04:45, Jordan LeDoux  wrote:
> 
> On Fri, Apr 8, 2022 at 10:35 AM Craig Francis  > wrote:
> https://wiki.php.net/rfc/null_coercion_consistency 
> 
> 
> 
> This RFC seems to be trying to force all PHP developers, regardless of what 
> *they* think, to treat null as "whatever the default value is within the type 
> context of execution", which is probably the most dangerous and bug-prone 
> usage of null in PHP code. This would make it almost impossible for most 
> programs to treat null instead as "an undefined value which must be 
> explicitly set", which is another usage I commonly see in code.


Not what I'm going for... but anyway, to get an idea of your position, do you 
think the string '15' should be coerced to a number, or should it fatal error 
as well? e.g.

$my_number = round($request->get('my_number'));

Craig

Re: [PHP-DEV] NULL Coercion Consistency

[Aleksander Machniak]

On 08.04.2022 19:34, Craig Francis wrote:

Hi,

I've written a new draft RFC to address the NULL coercion problems:

https://wiki.php.net/rfc/null_coercion_consistency


As a voter, I'm in favor of this RFC.

I suggest to rename "Documentation" section title to "Scalars coercion 
inconsistency" or sth like that, as this section isn't really much about 
the documentation, rather the current state.


--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

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