Hi
On 2026-10-09 10:21, Muhammed Arshid KV wrote:
I understand the concern about type safety. However, the real-world
usage
of filter_var() is worth considering too. Many use cases only require a
filter ID, without any flags. Sourcegraph search:
https://sourcegraph.com/search?q=context:global+lang:php+filter_var%5C%28&patternType=regexp&sm=0
If combined bitmasks are uncommon in practice, a Filter\Flag enum could
still improve the API for individual flags. I agree that we should
weigh
this benefit against the loss of type safety when combining flags.
An enum would slightly improve the API for the `filter_var()` use case
without any flags. But for `filter_var_array()` it already would no
longer work and for `filter_var()` with flags, it would result in a
weird mixture of a strong enum with “free form” options field.
I believe that introducing enums right now is not doing enough to
meaningfully improve the developer experience. As an example, if we
already had Tagged Unions (https://wiki.php.net/rfc/tagged_unions), the
per-filter options could be provided directly with the union case:
filter_var($foo, Filter\Int(allowOctal: true, allowHex: true));
Introducing the enum right now likely would block off that path.
Best regards
Tim Düsterhus
