Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130397
Message-ID: <aabe73db-682f-4cf6-bb9f-1168a06ed40c@bastelstu.be>
Date: Wed, 18 Mar 2026 21:32:56 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [VOTE] enum SortDirection
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: php internals <internals@lists.php.net>
References: <1f2191653ca5b8c0d9411cccfb9fc9f9@bastelstu.be>
 <CAAKU0ukasnNBgv7hC3T1aG_fv+_o7R_FvkJjVKS3dEyeRvLLCw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAAKU0ukasnNBgv7hC3T1aG_fv+_o7R_FvkJjVKS3dEyeRvLLCw@mail.gmail.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/18/26 19:38, Levi Morrison wrote:
> Tim, I am curious if adding a backing value in a future release would
> be considered a breaking change or not, something like:
> 
> enum SortDirection {
>      case Ascending = 1;
>      case Descending = -1;
> }
> 
> The exact values don't matter for my question, only whether or not it
> would be considered a backwards compatibility break.

That's complicated to answer. From a LSP POV changing a UnitEnum to a 
BackedEnum is just “adding new things” (and indeed the BackendEnum 
interface extends UnitEnum), which is safe from a backwards 
compatibility PoV. However I've seen folks doing `instanceof` checks in 
the folks to decide whether to use the ->name or ->value for 
serialization. Changing from UnitEnum to BackedEnum would introduce a 
behavioral change there.

All that said, I believe making an enum backed is almost always a 
mistake, since there is rarely a single obvious "blessed" scalar 
representation of an enum value, doubly so for the featured enum of this 
RFC, as explained by the RFC. See also the first paragraph of this email 
from me in another discussion thread: 
https://news-web.php.net/php.internals/129408

Best regards
Tim Düsterhus