Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127920
Content-Type: multipart/alternative;
 boundary="------------hoAIWd9jvkW6FOf40LSz5SWc"
Message-ID:
 <AM8P250MB017056034C85B7785F5A7AB8E24CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Date: Sun, 6 Jul 2025 18:11:25 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: "Gina P. Banyard" <internals@gpb.moe>,
 Niels Dossche <dossche.niels@gmail.com>, internals@lists.php.net
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
 <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
Content-Language: en-US
In-Reply-To: <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|AS4P250MB0893:EE_
X-MS-Office365-Filtering-Correlation-Id: 7c891a6d-6423-43d8-70ac-08ddbca7c269
X-Microsoft-Antispam:
	BCL:0;ARA:14566002|9400799033|461199028|8060799009|7092599006|15080799009|12050799012|12121999007|19110799006|41001999006|5072599009|56899033|3412199025|40105399003|440099028|10035399007|12091999003|26104999006;
X-Microsoft-Antispam-Message-Info:
	=?utf-8?B?emMwODgzazNwcDFEelY3MjBlRW5KQjViL2hJbXRxTWl5TStmQ003R09hRGlp?=
 =?utf-8?B?dFJTTVFMc0JmdU5Pb1lPWVVWbUl4ZWFDdjZjaXk4OUI4MzN2TTBnYjVQZTVw?=
 =?utf-8?B?M1ZsV3RnNnJWYlZNNEZLYjM0ekc1aS9RQjRCRGFwNmNIb0Q0bGh3cHhhMkJl?=
 =?utf-8?B?aVBLTGRDcis0RmpRb2lUTGRwM3Q4d01PM2JET2JCMG5CVWxMSm9jT3JZak9R?=
 =?utf-8?B?ZU5OVGNlM1MzSENMbys4MlEvL0NnT0t5eE10WFp4di8vR1d1dWpIaEUwY0Y5?=
 =?utf-8?B?d2UxNVFOcFJML0hjTTIwdXRLNHkzcWwrZWM3NVBXTE9TMGg0bms5M242bVJG?=
 =?utf-8?B?MjluOGl4N1dtZjcvRStHWERuSFVuMjJST1B4RjBIUzR0bFVka1hnTW1rWXFp?=
 =?utf-8?B?emp0RWYzYlNQb3lwamY0Y3hKTzIrQU5OSmxtUjVzcVlkaWd1S3plRFdOT3pz?=
 =?utf-8?B?c0xLVnA1Z1BnS0Mzd0lqei9KdWhCVnRQUm5BYW1FcEc3RlZ2YmQvbldxcmtR?=
 =?utf-8?B?NDZsREd4Qmk1aTA0NFFHUS9wNlRiQSszN240dHllSFVpY1NQNUVBK3FzTk1r?=
 =?utf-8?B?TkFMa2NuMzNNN0hpS2hhYllYWmREZkZMSktGSjdhYUhQS2FJRm4wTVhGc1V1?=
 =?utf-8?B?SS9yUTk5RlZjRUtSd05VR1RvV2dRL0g2RGwzSG5MRjlzYjc4dFpvdFAybitF?=
 =?utf-8?B?Rk1iOWJ3a0JhSHNENXJUUFQrM3J0NFh0ZjJuUXBkb05aVzJhdDZkNEhKbkls?=
 =?utf-8?B?Tmo1WmJrUVNjTzgxTVBwSHk2MG83enMzUC9nWU82K2FtdzViVzVtTFdFaVc4?=
 =?utf-8?B?MWhXdGZ1Zk5wMlBCN2RjUlNUbGVOQnVidXU2T3krMExkTjNPU3Q0bDh6Vkdr?=
 =?utf-8?B?QlVrVXlLSnRwZ0tGUFZWOUNhTFhwSjgzNlFDdm5QM0kwWnVKNWszcnFhb0VI?=
 =?utf-8?B?Mk9RYW1OdUlQRjNqY0hubm16NDVDZWNvVHZnWmhUQ3Z2UEhBc0lmOHkwV3Jh?=
 =?utf-8?B?QTBCY1BzQkFMK2x3Tk5RVHhnWFJNQU1wVk5hUjI1NnRXSFUzRVFNRkNSR2F6?=
 =?utf-8?B?cnRjNklGZXdLck1WMzIrYVVnVlFXQXlMUWdOSEErS2MxTThvK29Nb1VBRkZ2?=
 =?utf-8?B?UHR3S2dVRXZ4ZHR0aHhQRGR4QlMvaXZjTS9DcXl5RGV0eitRWWh3eWxMaWFy?=
 =?utf-8?B?bVBEeFRaSXNOYVJlRTg0YUFwTUlFVEVBdGdVdXppM1JzQmVUVEU0WmZPR3lj?=
 =?utf-8?B?RW5JdlNSejV3M2ltZzc4WHNQa1pjNmhhR0NQL0QxQWFONitCckJZWWk0cEVn?=
 =?utf-8?B?UGNpaHNFQ3BxUlJabys2RTlXa2RRUHErUE10UGVXenJMaHcxdnZ5TnMvamVr?=
 =?utf-8?B?ajRFUGlxUE1YTHJiOXZKZjBNOUVEUHZzVGFITHdpemtJaE9LVFl4Qy92WC81?=
 =?utf-8?B?V1NHeHArQnJSNDhpem5tV29zMEovZjVDdmIvVGJHbDlrTFVqb01PU2d5Wldq?=
 =?utf-8?B?VDhjRFh3YUp6TmZkdzd2Q3ZrYUVneDRKUHFqV1lVVnE3cVlsUDhZdGNJd0FN?=
 =?utf-8?B?Y1pRbEttY0xKQmsydzN5ejJtcjFmNitiZVpJR1p5UjlPUHRCaHlpSnR5bmdT?=
 =?utf-8?B?L0JJeWxWTTRPNDNrVnpiWllqRURCWWRCcXV5bnRKeXhEdWNUYmF5MGhwSXZF?=
 =?utf-8?B?UzlOVWptaDZtR3M0TkJYN3VZbXlpVnVnN0hKV3dzS3lFbkwyZnZkeGJ3QXgr?=
 =?utf-8?B?eXZBZkV2SjVDLzgwNUMwakNCNGVBSktrUStJTVpSNVZKVDBPWVZJRWY0Q2xv?=
 =?utf-8?B?cVBFWENJbUZKQlhrWjJhb2gvdWhTZ3lTajA0aEZrVEllbmh5UWdteXZocWhS?=
 =?utf-8?B?V2haaklLemVEZmRjMHlaY1BmdVdjRkRyKzFGQnNhTHA4NEE9PQ==?=
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?RkxGaDF4d2VlOE05MlhEdEh1OFV1T0FkN2hjRjRlWk82WGdiQTJqanZqaUN3?=
 =?utf-8?B?T1pIeER6QlhNYzJlWWQwS1hGNEdtU2ExUzFSL2orQndrd09hRS9GK1Zza2lT?=
 =?utf-8?B?L1JZendqV29UcE03Y0VWb1pUZkpkb1NuMHpyQU5jTWM5SmhUMWhGY2hZb0lt?=
 =?utf-8?B?VnAzeTBlanFLTEFFbU94OGdOaWdOSm1zY1hCUFo0b3pxOE9naFN0Q0d6c0Fj?=
 =?utf-8?B?c0ZPMkpDQWUvOHVUeWVaclVNU3lSc3I4YWlhMHlrZCtycFVkZ09mZit1OVM2?=
 =?utf-8?B?K21xTXMyWEE0b3NRTE94d0lZQUJFanR6WnVHWEhLRndrOVNibzVqNExUb2E0?=
 =?utf-8?B?TFNNdVIvUG9YVUROZDE2YzhDMkNzQlY1bFd5bUwyVlNDS09yeU1HaUN1cVlP?=
 =?utf-8?B?cDlIZk5na1VVSG1VaUYyYktjTVRNQnB1U0dRdDR3N3BMTEZ4L2ZEcHB1VmRS?=
 =?utf-8?B?R2ExYXpIUmlVb25YTUxvVWYzZVZuZlNEL1Z6bElUU090Rm4zSnRMbHVnU1lE?=
 =?utf-8?B?UTJVckJTbjFYdWc4MGttYWdSbU0wajg0aVJtbStYaEU1Y1RYcGQwalVuOWJ6?=
 =?utf-8?B?MXRDNmtsMlp5bFQ5d2x0Q3A3THdBbW1WN0FRQ0xmSGk5S0JhbnljUmdqUWFt?=
 =?utf-8?B?SnlXbGU2aEY1MnloNFc4VTFidkEwbzBpQ0J4dUpsQWwxaEtxSkVaZEhWYzlP?=
 =?utf-8?B?QVp4L2NiMHRqaGROTnQ5SUd5d2tyaEVhSFNzOWxBd09Sd2w5TTQzK1Z0bnFm?=
 =?utf-8?B?Rkg2ZCtVaDlxU1BySTVTUmhBU0ZPMFdyZ2h0VCtZbDRUNVg4Y1NMWDNreGI5?=
 =?utf-8?B?TTRncVl1OHVndVJzNXRYa2NTSDhGQXAyOFlGMHhGckg5ak9BS1N1R1NpZnl5?=
 =?utf-8?B?elRRbElnK2VUWlJNd2dweWdCeXVYbDNaZVh5cjF4UURSK04xbmdVSi91UVFS?=
 =?utf-8?B?d095b0RpU1VLRDNLaDJ4ZHlIOGpwQUtyWm9EYU4zNkxYRmlZbllxMlJ3bWt6?=
 =?utf-8?B?eG5peFlZZWFkQVN4ZFR0d1NRQk1ZMFZhS2pSWDZUb3plNDQ1VW1BdmxyK1hB?=
 =?utf-8?B?cUFMUFRrc1BPbDA3cWd0Z21CaUIyVTRTcVFZbjZCUXlHcXkrNENpaWhOZG9D?=
 =?utf-8?B?cEZyODNaaDBjWlo2TTEwbFFVdkIvUkVTTENvSmg4bHZLV3BuVng3bUtpUzMz?=
 =?utf-8?B?c0hEUU1xOUo2cUJtRFdFakdUNmN6OGJKbnVFdlM3cGVEakVsMFQ2ZDd3VlQ1?=
 =?utf-8?B?OGtEMHhaaVpKSWk1WVc0aklPamp3Nyt5MWVOd2dqTlhpby9oVWx2aDJnYk1x?=
 =?utf-8?B?N0VxYVZlMURIcHR5dzJHQmpHL2hMWUNaTi8yUC81YlBjcnYydVh6emF1ZFl0?=
 =?utf-8?B?TVcxN0taRmt0NUFMUW9iMk8rTWRJTWlEQy9pYm0wS2lscnZSc25iRk4yQnZW?=
 =?utf-8?B?Z1RERGhQREpBUHZDcnRaZjRueEsyWTdCa2pzR3RrYjNnVjQxTTRuSm01ZHVt?=
 =?utf-8?B?WndvcVlvTk9qcWVMOGdsbFJXbmdNU2FFRGw1RWljT01GWk13M2w2OVhsSWJU?=
 =?utf-8?B?QnJ2b2J0TGtKejlkMnBOZDRaMWs3U256N3dVQzdTMkpicDlqaUorZlY3c3dq?=
 =?utf-8?B?aStyemc2cVN2d2NOb1pEWWdUQStpVVJUVFNvNng3OHVOS3RFa1ROSHZ0UGIw?=
 =?utf-8?B?RjMycE90dFVMeCtwdG5tMzMwZGFWckNNS1R1V3I3Ukp4cUdPR0dJUVZHcGR4?=
 =?utf-8?Q?NOTCmrEEFhUxUD0gk8=3D?=
X-OriginatorOrg: sct-15-20-8534-15-msonline-outlook-5f066.templateTenant
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c891a6d-6423-43d8-70ac-08ddbca7c269
X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2025 16:11:26.8100
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg:
	00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4P250MB0893
From: bobwei9@hotmail.com (Bob Weinand)

--------------hoAIWd9jvkW6FOf40LSz5SWc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hey,

On 4.7.2025 09:01:52, Niels Dossche wrote:
> Hi
>
> First of all, that's a huge list of deprecations and I think we should tone down on that.
> Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.

Yeah, I agree. The list of deprecations is too big and possibly should 
be multiple RFCs. Let's keep it in mind for next year at least, please.

Deprecating should be a selective process, just like adding features is. 
I don't think we really have big RFCs which simply add a bunch of 
_unrelated_ stuff.

> Secondly, I'm tired of having to deal with useless deprecation messages.
> A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
> That leaves you needing to look up the documentation, which is also incomplete.
> Seehttps://github.com/php/php-src/issues/14320
> Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.
Good idea. I can support that.
> There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.
>
> There are a few things I will vote no for:
>
> * Deprecate semicolon after case in switch statement.
>    People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.
>
> * Deprecate attributes applying to multiple class properties/constants.
>    On the edge, confusing yes, but it might break real code.
>
> * Deprecate using values of type null and bool as array offsets and when calling array_key_exists()
>    Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.
>
> * Deprecate __debugInfo() returning null
>    Weird, especially as the docs say the return type is ": array", but not harmful.
>
> * Deprecate ReflectionParameter::allowsNull()
>    This shorthand doesn't hurt anybody, and is convenient, I don't see the point in deprecating it.
>
> * Deprecate passing spl_autoload_call() to spl_autoload_unregister()
>    This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
>    The behaviour may be weird, but notice that people won't do this by accident.
That one is probably just getting rid of the special casing in the code, 
which I'd support.
> * Deprecate passing null to readdir(), rewinddir(), and closedir()
>    Dubious but not really harmful I think.
>
> * Based on Derick's comments I will vote no on the ext/filter deprecations. I was already going to vote no on the filter_* functions though.
>
> * Deprecate driver specific PDO constants and methods
>    Too early.
>
> Kind regards
> Niels

To add to Niels list:

* Deprecate passing string which are not one byte long to ord()
   This behaviour is consistent with mb_ord() as well. If we deprecate 
one, we also should deprecate the other. But that makes no sense, 
because the latter is not fixed with. So let's just not deprecate either.

* Some INI deprecations:

** Deprecate the docref_root and docref_ext INI directives
    What's the point? Why do these need to be deprecated? If these are 
not set you do not get clickable links at all, unrelated to mirrors and 
such.

** Deprecate the error_prepend_string and error_append_string INI directives
    Why is that of questionable use? Why is "this is a development and 
debugging feature" considered a valid reason to get rid of something? It 
allows prominently displaying issues in development when they would be 
hidden behind other HTML otherwise.

** Deprecate the report_memleaks INI directive
    So, "I'm currently working with this code having a known memory leak 
and I want to suppress it" is not a valid reason? If you select that 
that's a very deliberate opt-in.

Bob

--------------hoAIWd9jvkW6FOf40LSz5SWc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p>Hey,<br>
    </p>
    <div class="moz-cite-prefix">On 4.7.2025 09:01:52, Niels Dossche
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com">
      <pre wrap="" class="moz-quote-pre">Hi

First of all, that's a huge list of deprecations and I think we should tone down on that.
Especially if a feature still has a purpose and is not harmful or buggy, then we should probably consider not deprecating it.</pre>
    </blockquote>
    <p>Yeah, I agree. The list of deprecations is too big and possibly
      should be multiple RFCs. Let's keep it in mind for next year at
      least, please.<br>
    </p>
    <p>Deprecating should be a selective process, just like adding
      features is. I don't think we really have big RFCs which simply
      add a bunch of _unrelated_ stuff.<br>
    </p>
    <blockquote type="cite" cite="mid:eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com">
      <pre wrap="" class="moz-quote-pre">
Secondly, I'm tired of having to deal with useless deprecation messages.
A lot of deprecation messages are completely useless for developers because they do not point to a reason or a replacement.
That leaves you needing to look up the documentation, which is also incomplete.
See <a class="moz-txt-link-freetext" href="https://github.com/php/php-src/issues/14320">https://github.com/php/php-src/issues/14320</a>
Therefore, any deprecation proposed in this RFC that does not explicitly list the deprecation message, I will vote no for.</pre>
    </blockquote>
    Good idea. I can support that.<span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
    <blockquote type="cite" cite="mid:eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com">
      <pre wrap="" class="moz-quote-pre">There are some things in the list I don't care about or I don't have a lot of insight of its uses in, and I will abstain for voting on them.

There are a few things I will vote no for:

* Deprecate semicolon after case in switch statement.
  People seem to use this and it doesn't seem harmful to have. Just because you don't like it doesn't mean we should yeet it.

* Deprecate attributes applying to multiple class properties/constants.
  On the edge, confusing yes, but it might break real code.

* Deprecate using values of type null and bool as array offsets and when calling array_key_exists()
  Deprecating this would make the language more inconsistent by allowing this on array offsets but not on the function.

* Deprecate __debugInfo() returning null
  Weird, especially as the docs say the return type is &quot;: array&quot;, but not harmful.

* Deprecate ReflectionParameter::allowsNull()
  This shorthand doesn't hurt anybody, and is convenient, I don't see the point in deprecating it.

* Deprecate passing spl_autoload_call() to spl_autoload_unregister()
  This is very ad hoc, and as Ilija pointed out, we can't prevent workarounds for this. So what's the point really.
  The behaviour may be weird, but notice that people won't do this by accident.</pre>
    </blockquote>
    That one is probably just getting rid of the special casing in the
    code, which I'd support.<br>
    <blockquote type="cite" cite="mid:eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com">
      <pre wrap="" class="moz-quote-pre">
* Deprecate passing null to readdir(), rewinddir(), and closedir()
  Dubious but not really harmful I think.

* Based on Derick's comments I will vote no on the ext/filter deprecations. I was already going to vote no on the filter_* functions though.

* Deprecate driver specific PDO constants and methods
  Too early.

Kind regards
Niels</pre>
    </blockquote>
    <p>To add to Niels list:</p>
    <p>* Deprecate passing string which are not one byte long to ord()<br>
      &nbsp; This behaviour is consistent with mb_ord() as well. If we
      deprecate one, we also should deprecate the other. But that makes
      no sense, because the latter is not fixed with. So let's just not
      deprecate either.<br>
    </p>
    <p>* Some INI deprecations:</p>
    <p>** Deprecate the docref_root and docref_ext INI directives<br>
      &nbsp;&nbsp; What's the point? Why do these need to be deprecated? If these
      are not set you do not get clickable links at all, unrelated to
      mirrors and such.</p>
    <p>** Deprecate the error_prepend_string and error_append_string INI
      directives<br>
      &nbsp;&nbsp; Why is that of questionable use? Why is &quot;this is a development
      and debugging feature&quot; considered a valid reason to get rid of
      something? It allows prominently displaying issues in development
      when they would be hidden behind other HTML otherwise.</p>
    <p>** Deprecate the report_memleaks INI directive<br>
      &nbsp;&nbsp; So, &quot;I'm currently working with this code having a known memory
      leak and I want to suppress it&quot; is not a valid reason? If you
      select that that's a very deliberate opt-in.<br>
    </p>
    <p>Bob<br>
      <br>
    </p>
  </body>
</html>

--------------hoAIWd9jvkW6FOf40LSz5SWc--