Re: NULL Coercion Consistency

Hi, > https://wiki.php.net/rfc/null_coercion_consistency Thanks for the draft. On Sat, Apr 9, 2022 at 11:30 AM Craig Francis <craig@craigfrancis.co.uk> wrote: > On Fri, 8 Apr 2022 at 19:07, Craig Francis <craig@craigfrancis.co.uk> > wrote: > > > On Fri, 8 Apr 2022 at 18:54, Mel Dafert <mel@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"). Regards, -- Guilliam Xavier