Re: RFC Idea - is_json - looking for feedback

Still new here so what I say probably doesn't amount to much, but I too see this as encouraging the generally-less-appropriate sequence of: parse to determine if it's valid JSON via is_json(); and then parse again using json_decode() The name is_valid_json() rings truer to me because we are dealing with values that may or may not be "JSON" even if they can parse as such. For example, the string "false" is valid JSON _if interpreted as JSON_ but need not _be_ JSON in truth. The same is true for "[1, 2, 3]" and even still I suppose it's possible to have a string value that works as a JSON map _if interpreted as JSON_ but that data may not have been created with the purpose of being JSON. Again, it's _valid JSON_ if interpreted that way, but may not in fact _be_ JSON. That being said, the idea of putting this behind filter_var() seems like it would do less to encourage poor practice (as in, it would be a good thing). That one is likely harder to find, doesn't sound as appealing as is_json() or is_valid_json(), and would stick out more if someone were to use it casually where json_decode() alone is more appropriate. Also that function already deals with validation and provides a way to pass the options we would need (max depth, JSON_INVALID_UTF8_SUBSTITUTE, and JSON_INVALID_UTF8_IGNORE) if we wanted this to match the behavior of json_decode(). The examples you found are good motivations for a leaner validation check, but I wonder if they actually represent a great need. If a good user-space solution exists those few frameworks could use that effectively and presumably the need for a core function would disappear. I think personally I would rather see this go through if our performance improved substantially more than it shows in the posted benchmarks. While I realize what you are doing so far is reusing the existing JSON parser and so we shouldn't expect an entirely different performance profile, I agree with the others that the implementation here is somewhat intrinsically bound with the idea itself. In comparison I have created a naive version in PHP itself with PCRE calls advancing the JSON tokenization: https://pastebin.com/Cf8BZn1H There are certainly glaring bugs in this because I tossed it together while on a train and only wanted to get a reasonable approximation of the performance characteristics for in-PHP code. In your benchmark it runs about twice as slow as json_decode() but uses essentially no memory (matching your results with is_json()). I'm pretty sure there are easy ways to eliminate some low-hanging performance bottlenecks, though it doesn't check for valid UTF8 or valid escaped strings or check for a maximum depth. I feel like if we are going to add a new native function for this it should be way faster than four times as fast as a primitive function in PHP user-space. Warmly, Dennis Snell