Filter\Filter and Filter\Flag enums proposal (formerly: deprecate invalid Filter options)

Under discussion; not accepted. On 7 October the author rewrote the RFC at the same URL. Instead of deprecating invalid options, it now proposes adding Filter\Filter and Filter\Flag enums. The page (last modified 2026-10-07 06:06 UTC) is titled "Add Filter\Filter and Filter\Flag Enums" and its status is Under Discussion. It still says version 0.9 and dated 2026-10-03. Its changelog says: "2026-10-07: Revised RFC to reflect the enum implementation in php-src PR #24111." When the official RFC index was collected at 10:01 UTC on 7 October, it listed the page under that title as discussion. Earlier collections did not list it. At 04:16 UTC the author asked for feedback on the updated proposal in the original thread.

Current proposal (7 October revision)

• Two int-backed enums in the Filter namespace: Filter\Filter, with cases from DEFAULT and VALIDATE_BOOL through SANITIZE_ADD_SLASHES and CALLBACK, and Filter\Flag, with cases such as NONE, ALLOW_OCTAL, ALLOW_HEX, IPV4, IPV6 and GLOBAL_RANGE. Each case is backed by the value of the existing FILTER_* constant. The listed Filter\Filter cases include SANITIZE_STRING, whose constant has been deprecated since PHP 8.1. The RFC does not comment on this.
• filter_var(), filter_var_array(), filter_input() and filter_input_array() would accept the enums as well as integers, including in 'filter'/'flags' array definitions.
• To combine flags you use their backing values, for example Filter\Flag::ALLOW_OCTAL->value | Filter\Flag::ALLOW_HEX->value.
• The RFC says no constants are removed or changed and integer arguments stay accepted. The proposed version is PHP 8.7, and the vote template is a single 2/3 question. No vote is scheduled. The implementation is php-src PR #24111. Its state was not re-checked in this cycle.

Some text from the earlier draft remains on the page. "Future Scope" still says the RFC "is limited to invalid integer-valued filter and flags options". The ecosystem impact section still says invalid option values "will no longer be silently accepted". Neither statement matches the enum-only proposal. On 9 October (page last modified 08:03 UTC) the author changed the vote question to "Implement Filter\Filter and Filter\Flag enums as outlined in the RFC?" (2/3 majority). The widget still shows 0/0/0 with the generic "This poll has been closed" footer, and no ballot has taken place. The Future Scope and ecosystem text quoted above was unchanged at that time.

Feedback on 9 October

Tim Düsterhus replied that requiring the backing value to combine flags as a bitmask "is an abuse of enums" that cancels their type safety and makes them "fancy constants". They also pointed out the unchanged vote template. The author answered that many filter_var() calls pass only a filter ID with no flags (citing a Sourcegraph search), that a Filter\Flag enum could still help for single flags, and that this should be weighed against the loss of type safety when flags are combined. The author did not announce a change to the flag design.

Tim Düsterhus answered again at 12:22 UTC. They said enums would help filter_var() calls without flags only slightly, would not work for filter_var_array(), and would mix a strong enum with a free-form options field when flags are used. They argued that, if PHP had tagged unions, per-filter options could be passed with the case (for example Filter\Int(allowOctal: true, allowHex: true)), and that adding the enums now would likely block that path. The tagged unions RFC (2020) is listed as inactive in the official index and is not part of PHP.

History: the invalid-option deprecation draft

As first published, the RFC page (version 0.9, dated 2026-10-03, last modified 2026-10-03 05:37 UTC) had the status Draft. Its implementation, discussion and voting threads were marked "tbd". The author announced it on internals at 05:38 UTC on 3 October (message 132778), describing it as opened for feedback. When the official RFC index was collected at 10:01 UTC that day, the RFC was not yet listed, and it was still absent from the index collected at 22:01 UTC. The page contained an unfilled vote template ("Implement $feature…", 0/0/0). No ballot has taken place.

The first on-list reply, from Calvin Buckley at 20:22 UTC on 3 October (message 132779), called the proposal reasonable "at first glance". It suggested possible follow-on RFCs: turning the filter types into an enum and removing the SAPI-side input filters for superglobals. These are one participant's suggestions, not part of this RFC.

At 08:38 UTC on 4 October the author, Muhammed Arshid KV, replied (message 132780). The author agreed that the filter types "would be better handled as a separate, focused RFC for enums" and wrote: "I'll close this RFC and pursue the enum proposal separately". The reply links php-src PR #24111, opened on 4 October. The PR adds backed enums Filter\Filter (filter IDs) and Filter\Flag (flags), which filter_var(), filter_input() and related functions would accept alongside the existing integer constants. Those constants are kept, and alias constants that share a value get only one enum case. As of 4 October no RFC page for the enum proposal was in the official index, and the PR's requested code-owner reviews were still pending. It is an implementation proposal, not an accepted change. The reply does not say whether the invalid-option deprecation will return in another form.

On 4 October at 16:11 UTC a php-src maintainer (iluuu1994) commented on PR #24111 and asked the author to start a mailing-list discussion first. The maintainer added: "I'm not sure it's a good idea to extend this API further." The author agreed. At 03:29 UTC on 5 October the author opened a discussion thread for the enum proposal. They described the enums as type-safe and more discoverable alternatives to the integer constants, which remain supported. They asked for feedback on the API, naming and approach "before preparing the RFC". When checked at 04:01 UTC, no enum RFC page was listed in the official index. The PR was open, had no submitted reviews, and was labelled "RFC" and "ABI break".

On the original thread, Derick Rethans replied to the suggestion of removing SAPI-side input filters that removing the filter defaults "was a mistake" and that the deprecation "ought to be undone, before the extension gets refreshed" (quoted in the author's reply). At 15:15 UTC on 6 October the author answered that the enum PR only aims to modernize the API, and that they will look into the history of the removed defaults before proceeding. As of 6 October no new RFC page or status change had followed.

That draft targeted the integer-valued filter and flags options of filter_var(), filter_var_array(), filter_input() and filter_input_array(). The draft said some invalid values are currently converted to integers silently. Under that draft, PHP 8.7 would emit E_DEPRECATED and PHP 8.8 would throw ValueError. The examples cover two cases:

• a value of the wrong type, such as 'flags' => 'abc' or 'filter' => 'abc' ("must be of type int, string given");
• an integer that matches no known value, such as 10050 ("Unknown flags with ID…" / "Unknown filter with ID…").

The draft's backward-compatibility section said that code that relies on implicit conversion of invalid values to integers would need to use the appropriate constants instead.

The deprecation described above was the content of version 0.9 before the 7 October rewrite. The current page no longer proposes it, and the author has not said whether it will return.

Limitations: the earlier draft's introduction mentioned an array passed as flags, but its examples used strings and unknown integers. The current enum proposal may still change; its naming, the flag-combination approach and the API-extension concern raised on the PR are open. This page does not describe current behavior beyond what the RFC states. Related: bcrypt length proposal, which uses the same 8.7/8.8 deprecation-then-error schedule.