note 129113 added to function.json-validate

It would have been very nice if the author(s) of this function had provided an estimate of how much RAM would be required to decode the JSON, how many of each type (string, object, array, etc), and other relevant statistics instead of just returning a simple boolean and, when JSON is invalid, provide details about why the input string is invalid JSON (e.g. "invalid char at 1537" or similar). json_last_error_msg() doesn't provide sufficient details about why decoding failed while plenty of other JSON decoding libraries can specify the character and most even provide line number + line position information where decoding failed. I'm not thinking of any real world use cases where I'd call this over just calling json_decode(). If this function returned potentially valuable statistical information or fixed malformed JSON such that a returned string would successfully decode or did something more than what it does now, then that would be something interesting and perhaps useful. As it stands, I don't think I'll ever use this function. Seems like an oddball function to feature as an 8.3.0 headliner. So I went and found the RFC (you are welcome): https://wiki.php.net/rfc/json_validate The original RFC doesn't convince me that this should be in core. Not even the security oriented reduced attack surface/denial of service prevention argument is sufficient, which I'm usually a strong proponent of. The official documentation here doesn't even offer this argument as a reason to call the function. So the exclusion of the security oriented argument from this documentation is either an oversight or is an extremely weak argument (you decide for yourself). The lack of additional features over json_decode() doesn't help its case any. All of the examples in the RFC of where this function could be used are from major pieces of software, so it is easy to understand WHY it passed the RFC vote process. However, those major pieces of software are almost certainly "doing it wrong" with their "IsJSON()" functions! Also, the authors of those software products (i.e. actual stakeholders in a json_validate() function) weren't consulted during the RFC process to get their feedback/input. This exemplifies the problem with the PHP RFC process: It's long, convoluted, hard to keep track of, gets lots of feedback in an echo chamber, and doesn't take into account real world usage patterns that might be flawed by design nor always show awareness of the larger picture. Ultimately, the PHP community gets a poorly documented, insufficiently fleshed out function linked to in the announcement of a release without explanation of why the function exists...assuming the function even gets documented at all. It just exists unless someon e goes around digging up the original RFC to produce postmortem commentary. ---- Server IP: 45.112.84.4 Probable Submitter: 45.91.157.134 (proxied: 174.18.52.89) ---- Manual Page -- https://php.net/manual/en/function.json-validate.php Edit -- https://main.php.net/note/edit/129113 Del: integrated -- https://main.php.net/note/delete/129113/integrated Del: useless -- https://main.php.net/note/delete/129113/useless Del: bad code -- https://main.php.net/note/delete/129113/bad+code Del: spam -- https://main.php.net/note/delete/129113/spam Del: non-english -- https://main.php.net/note/delete/129113/non-english Del: in docs -- https://main.php.net/note/delete/129113/in+docs Del: other reasons-- https://main.php.net/note/delete/129113 Reject -- https://main.php.net/note/reject/129113 Search -- https://main.php.net/manage/user-notes.php