Re: [RFC] Deprecate Invalid Filter Options
| From: | Muhammed Arshid KV | Date: | Fri, 09 Oct 2026 08:21:21 +0000 |
| Subject: | Re: [RFC] Deprecate Invalid Filter Options | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132847@lists.php.net to get a copy of this message | ||
Thanks for the feedback!
On Fri, 9 Oct 2026 at 13:04, Tim Düsterhus <tim@bastelstu.be> wrote:
> Enums are strongly typed values by themselves. Requiring the use of a /
> the backing value for some functionality (in this case: Passing multiple
> options as a bitmask) is an abuse of enums, nullifies the type safety
> and makes them “fancy constants” in practice.
>
> With regarding to the “formal parts” of the RFC, I'm noting that the
> “Voting Choices” section is unchanged from the template. In particular,
> the voting widget's title needs to be updated.
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.
I’ve updated the “Voting Choices” section.
Best regards
Muhammed Arshid