On Mon, Oct 3, 2022 at 11:29 AM Max Semenik <maxsem.w...@gmail.com> wrote:
> > Is there a compelling need to have this in the core, as opposed to > Composer packages? The ecosystem has changed a lot since the original > function was introduced. > I don't know that there is, I suspect the answer is probably not and sanitization and validation is probably better left to userland code. The only argument I can offer as devil's advocate is that certain validations or transformations will be faster in core than in library scripts. I would wager the most common implementation of such userland libraries today are heavily reliant on preg_* functions so having some fast, low level baseline in core for common tasks in this category might still make sense. While we're on the topic, can I bring up FILTER_SANITIZE_NUMBER_FLOAT? Why is the default behaviour of FILTER_SANITIZE_NUMBER_FLOAT the same as FILTER_SANITIZE_NUMBER_INT unless you add extra flags to permit fractions? Why is the constant name FILTER_SANITIZE_NUMBER_FLOAT but its counterpart for validation is FILTER_VALIDATE_FLOAT (no NUMBER_)? Why does validating a float return a float but sanitizing a float return a string? What about FILTER_VALIDATE_EMAIL which is notorious for being next to useless? Seems to me like there could at the very least be a plausible case for some better to_float(), to_int(), is_valid_email() etc. type functions in core to replace some of the filter API.
