This topic was discussed in the past as "Declaration-aware
attributes", and mentioned in the discussion to "Amendments to
Attributes".
I now want to propose a close-to-RFC iteration of this.
(I don't have RFC Karma, my wiki account is "Andreas Hennings (donquixote)")
-
Primary proposal
==
On Wed, Jul 2, 2025, at 2:25 PM, ignace nyamagana butera wrote:
>>
>> I don't think it needs to be added to the enum, necessarily. Just make it a
>> nullable argument to base64_decode.
>>
>> function base64_decode(string $string, bool $strict = false, ?DecodingMode =
>> null): string|false
>>
On Wed, Jul 2, 2025, 21:58 Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to
> add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
> year
On Wed, Jul 2, 2025, at 2:56 PM, Gina P. Banyard wrote:
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations
> to add in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
>
>
>
> I don't think it needs to be added to the enum, necessarily. Just make it
> a nullable argument to base64_decode.
>
> function base64_decode(string $string, bool $strict = false, ?DecodingMode
> = null): string|false
>
> That would leave the default behavior of the function intact, but also
On Jul 2, 2025, at 4:56 PM, Gina P. Banyard wrote:
>
> Hello internals,
>
> It is this time of year again where we proposed a list of deprecations to add
> in PHP 8.5:
>
> https://wiki.php.net/rfc/deprecations_php_8_5
>
> As a reminder, this list has been compiled over the course of the past
Hi
Am 2025-06-28 07:06, schrieb Larry Garfield:
Hi folks. Arnaud and I would like to present take-2 at Partial
Function Application.
https://wiki.php.net/rfc/partial_function_application_v2
I've now had a *quick* look at the implementation and the following
questions came up that the RFC d
On Wed, Jul 2, 2025, at 10:48 AM, Eric Norris wrote:
> Having thought about this some more, while I'm still feeling somewhat
> positive about my suggestion I'm just not sure it's the best way to
> proceed. I started to sketch what a BasicHttpHandle class would look
> like, and I'm stuck on how to
On Wed, Jul 2, 2025, at 10:48 AM, Eric Norris wrote:
>> Based on the feedback so far (I do plan on waiting for more responses
>> to your email), and on my own preferences, I wonder if there is a
>> hybrid option I could propose. Perhaps the RFC could offer both a
>> \Curl\Handle (tentative name) to
On Wed, Jul 2, 2025, at 10:10 AM, ignace nyamagana butera wrote:
>> > Perhaps we should include an option in the new API to emulate the old
>> > behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated
>> > with a note in the manual, similar to the MT_RAND_PHP mode in the
>> > Ra
Am 01.07.2025 um 14:40 schrieb Gina P. Banyard :
>> The RFC talks about "from" AND "to" bool conversion but the examples under
>> Backward Incompatible Changes only seem mention "from" bool, is that correct?
>
> I didn't think adding examples for "to" bool was useful, but I can add some.
Thanks!
On 1 July 2025 22:27:14 BST, ignace nyamagana butera
wrote:]
>- The current base64_decode function operates in a lenient mode by default,
>accepting characters outside the valid Base64 alphabet and ignoring
>the padding character wherever it is in the string.
>
> base64_decode('dG9===0bw??',
Hi internals,
Two weeks ago, after discussions about the PHP 30th event in Amsterdam with
some core developers and in the foundation, we introduced some changes to
the RFC Template.
The changes were aimed at reflecting current practices and requirements for
RFCs and making it more approachable for
>
> > Perhaps we should include an option in the new API to emulate the old
> behaviour, named as "legacy" or "unsafe" and immediately soft-deprecated
> with a note in the manual, similar to the MT_RAND_PHP mode in the
> Randomizer API <
> https://www.php.net/manual/en/random-engine-mt19937.constru
Hi Tim,
We will update the RFC, but here are a few answers:
On Wednesday, July 2nd, 2025 at 17:05, Tim Düsterhus wrote:
> I've now had a quick look at the implementation and the following
> questions came up that the RFC does not answer (and the tests in the PR
> do not obviously answer either):
> Based on the feedback so far (I do plan on waiting for more responses
> to your email), and on my own preferences, I wonder if there is a
> hybrid option I could propose. Perhaps the RFC could offer both a
> \Curl\Handle (tentative name) to address position 1, and a
> \Curl\BasicHttpHandle (also
> On Jul 2, 2025, at 10:48, Eric Norris wrote:
>
>> Based on the feedback so far (I do plan on waiting for more responses
>> to your email), and on my own preferences, I wonder if there is a
>> hybrid option I could propose. Perhaps the RFC could offer both a
>> \Curl\Handle (tentative name) to a
Hi all,
> The question of PHP-native request/response objects has come up a couple of
> times, and even had an RFC that went to a vote (declined). My stance has
> been, and remains, that ... they should be powerful enough to effectively
> replace/displace PSR-7.
Where and when have you previo
On Wed, Jul 2, 2025, at 12:34 PM, Paul M. Jones wrote:
> Hi all,
>
>> The question of PHP-native request/response objects has come up a couple of
>> times, and even had an RFC that went to a vote (declined). My stance has
>> been, and remains, that ... they should be powerful enough to effective
On Wednesday, 2 July 2025 at 17:26, Arnaud Le Blanc wrote:
> On Wednesday, July 2nd, 2025 at 17:05, Tim Düsterhus t...@bastelstu.be wrote:
> > is_callable($f, callable_name: $name);
> > var_dump($name);
>
>
> Closure::__invoke (like FCCs)
I'm slightly hijacking this to mention that this seems l
Hi all,
> On Jul 2, 2025, at 12:41, Larry Garfield wrote:
>
> On Wed, Jul 2, 2025, at 12:34 PM, Paul M. Jones wrote:
>> Hi all,
>>
>>> The question of PHP-native request/response objects has come up a couple of
>>> times, and even had an RFC that went to a vote (declined). My stance has
>>>
Hello internals,
It is this time of year again where we proposed a list of deprecations to add
in PHP 8.5:
https://wiki.php.net/rfc/deprecations_php_8_5
As a reminder, this list has been compiled over the course of the past year by
various different people.
And as usual, each deprecation will
Hi internals,
I would like to propose extending the target of the #[Override] attribute to
include properties.
The original RFC explicitly excluded properties [1] for reasons that have since
then changed drastically: the additions in 8.4 have allowed properties to
become a more prominent part
23 matches
Mail list logo
