Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130228
Message-ID: <19249e75-ba91-42fa-8eb4-3ef1375f0497@bastelstu.be>
Date: Mon, 2 Mar 2026 23:12:56 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] enum SortDirection
To: Bob Weinand <bobwei9@hotmail.com>, PHP internals <internals@lists.php.net>
References: <5bec7fdd-e2d0-47ab-92d0-ead8eade21e6@bastelstu.be>
 <AM8P250MB01705C4FC45781D33C5A110EE27EA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Content-Language: en-US
In-Reply-To: <AM8P250MB01705C4FC45781D33C5A110EE27EA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 3/2/26 22:43, Bob Weinand wrote:
> That's a good idea, but I wouldn't introduce such class without some
> usages at least.
> 
> I'd recommend considering immediately upgrading the proposed functions
> to use SortDirection and redefine the constants in terms of the enum.
> 
> I.e. set const SORT_ASC = SortDirection::Ascending; - similar for others
> like the SCANDIR_SORT_DESCENDING etc..
> 
> This is a reasonable BC break, which is also trivially fixed by simply
> accepting int|SortDirection in existing functions.

A GitHub search for "language:PHP SORT_ASC" reveals that the existing 
constants are used in userland code for custom purposes (e.g. within a 
`switch()` statement). Redefining them to the enum would bring little 
value, but unnecessarily break them. See also 
https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum 
for a precedent (specifically the Future Scope section there).

As suggested in the “Future Scope” of the featured RFC widening the core 
functions to accept the enum and update the default value to the enum 
case can just happen without an RFC, since this should not be observable 
except by Reflection.

I want to avoid a situation of explicitly listing *some* of the 
functions in the RFC, missing one and then later having a discussion of 
whether or not it requires a follow-up RFC to *also* adjust that missed one.

Best regards
Tim Düsterhus