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

Thanks for the draft.

On Sat, Apr 9, 2022 at 11:30 AM Craig Francis <cr...@craigfrancis.co.uk>

> On Fri, 8 Apr 2022 at 19:07, Craig Francis <cr...@craigfrancis.co.uk>
> wrote:
> > On Fri, 8 Apr 2022 at 18:54, Mel Dafert <m...@dafert.at> wrote:
> >
> >> In particular, does this propose changing user-defined functions under
> >> strict_types=0 to accept null for scalar types?
> >>
> >
> > With user defined functions, I think it's up for debate (still a draft),
> > but I think those NULL's should be coerced to the specified type (as
> > documented), where I don't think PHP should be doing type checking under
> > strict_types=0.
> >
> I've updated the RFC to note that user-defined functions don't cause a
> backwards compatibility issue; but I have added an example to highlight
> the coercion inconstancy:

You've updated the **Documentation** section (also: did you mean
"inconsistency" rather than "inconstancy"?) but still not the **Proposal**
(BTW all those sections between "Introduction" and "Proposal" would
probably better be *sub*-sections of a section named "Problem" or "Current
State" or something).

And for the question: (currently) the RFC is named "NULL Coercion
*Consistency*" and the Proposal says "Must keep the spirit of the original
RFC, and *keep user-defined and internal functions consistent*.", which (to
me) implies *not only* reverting the 8.1 deprecation on internal functions
*but also* "changing user-defined functions under strict_types=0 to
[coerce] null for scalar type[ declaration]s" indeed.
In any case, that should be written clear in the RFC (either in "Proposal"
or "Open Issues").


Guilliam Xavier

Reply via email to