Re: [PHP-DEV] [DISCUSSION] Adding the "is_integer_safe()" function

> Le 26 juil. 2025 à 18:13, Alexandre Daubois a > écrit : > >> >> I'm not sure if accepting floats in the same function makes sense. If the >> question is "can this value safely be stored in a float?" and you give it a >> float, then the answer is surely "yes". You have no way of knowing if

Re: [PHP-DEV] Validating #[\Attribute] targets

> Le 25 juil. 2025 à 18:37, Daniel Scherzer a > écrit : >  > Hi internals, > > The #[\Attribute] attribute is used to mark classes as being usable as > attributes. It currently does not trigger any error if added to a trait, > interface, enum, or abstract class. However, if any of those *we

Re: [PHP-DEV] [RFC] Warnings for PHP 8.5

> Le 14 juil. 2025 à 18:23, Gina P. Banyard a écrit : > Hello internals, > > Similar to the mass deprecation RFC, I would like to propose the addition of > a few warnings in certain situations: > https://wiki.php.net/rfc/warnings-php-8-5 > > I am expecting these 4 sub-proposals to be mostly

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 22 juil. 2025 à 11:25, Rob Landers a écrit : > > >> >>> Should I be able to mark this class as readonly? I would think so. >> >> >> I don’t think so. >> >> If you want to *document* the intended invariant, you can put a @readonly >> tag in a phpdoc comment. >> >> Adding a `readonly`

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 22 juil. 2025 à 09:43, Rob Landers a écrit : > > You can also implement this today, without using readonly: > > class Foo { > public int $bar { > get => $this->bar; > set => empty($this->bar) ? $this->bar = $value : throw new > LogicException("nope"); > } > } > > https://3v4

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 19 juil. 2025 à 09:46, Rob Landers a écrit : > > > > On Sat, Jul 19, 2025, at 03:04, Claude Pache wrote: >> >> >> >>> Le 19 juil. 2025 à 00:41, Rob Landers a écrit : >>> >>> The original author (Nikita) suggested tha

Re: [PHP-DEV] Re: [RFC] Readonly property hooks

> Le 19 juil. 2025 à 00:41, Rob Landers a écrit : > > The original author (Nikita) suggested that there's nothing in the original > design that precludes accessors -- and highlights languages where there are > both and they are doing just fine more than 5 years later. Hi Rob, It is indeed e

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5

> Le 10 juil. 2025 à 13:18, Gina P. Banyard a écrit : > > On Wednesday, 9 July 2025 at 22:26, Claude Pache > wrote: >> Hi, >> >> A possible reason for wanting to use the non-canonical names in settype(), >> is that those names are returned by gettype().

Re: [PHP-DEV] [RFC] [Discussion] CHIPS

> Le 15 juil. 2025 à 12:09, Dmitry Derepko a écrit : > > Hi internals, > > In collaboration with Niels Dossche I'd like to start the discussion for an > RFC proposing a new Cookie option for use with CHIPS technology. > > As Niels noted, today is the day when in 4 weeks there will be code fr

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 11 juil. 2025 à 11:38, Nick a écrit : > > > I am afraid here I do have a strong opinion. Please remember my very first > mail before discussion [1]. > While for Larry the main reason for `readonly` hooks is lazy-initialisation, > for me it is to write less code, to have less noisy class

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 11 juil. 2025 à 06:30, Nick a écrit : > > Hey all, > >> On 8. Jun 2025, at 11:16, Larry Garfield wrote: >> >> As Nick has graciously provided an implementation, we would like to open >> discussion on this very small RFC to allow `readonly` on backed properties >> even if they have a h

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5

> Le 9 juil. 2025 à 14:21, Gina P. Banyard a écrit : > > On Wednesday, 9 July 2025 at 08:17, Daikaras wrote: >> >>> We propose to deprecate the following non-standard cast names: >>> >>> (integer) >>> (boolean) >>> (double) >>> (binary) >> Hello, >> >> Just wondering is this going to affect

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 9 juil. 2025 à 15:17, Nick a écrit : > > Hey Claude, > > > I hear you, but I still struggle to fully grasp the issue. It’s genuinely > hard for me to come up with a real-world example that actually makes sense. > Everything I’ve seen so far, including the RFC example and what I tried >

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 8 juil. 2025 à 17:32, Nicolas Grekas a > écrit : > > I read Claude's concern, and I agree with Larry's response: the engine > already allows readonly to be bypassed using __get. The added hook doesn't > make anything more lenient. > It is true that readonly could be bypassed by __get(

Re: [PHP-DEV] Deprecate return by reference from never ?

> Le 9 juil. 2025 à 02:47, Juliette Reinders Folmer > a écrit : > > L.S., > > I just noticed something which seems odd to me: PHP 8.1 deprecated declaring > a function to return by reference when the return type is void: > > `function &foo() : void {}` results in: > "Deprecated: foo(): Retu

Re: [PHP-DEV] [Discussion][RFC Idea] Cast Variables by Reference

> Le 7 juil. 2025 à 18:22, Joseph Leedy a écrit : > > Hello, I'm Joseph, or Seph for short. I'm a long time listener, but a > first-time caller. I've had an idea rattling around in my noggin for a while > that I'd like your feedback on: > > As a developer, I would like to have variables of o

Re: [PHP-DEV] [Discussion] Cookies Having Independent Partitioned State (CHIPS)

> Le 6 juil. 2025 à 13:25, Tim Düsterhus a écrit : > > Hi > > On 7/5/25 13:52, Dmitry Derepko wrote: >> I want to allow the "Partitioned" key to be set. Shall I open RFC or is it >> possible to create only PR with improvements? >> Also, I think it may be backported to all the actual PHP versio

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5

> Le 2 juil. 2025 à 21:56, Gina P. Banyard a écrit : > > 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 Hi, To reduce noise, I’ll be short. General remark: For each deprecation, please research f

Re: [PHP-DEV] [RFC] Readonly property hooks

> Le 8 juin 2025 à 06:16, Larry Garfield a écrit : > > As Nick has graciously provided an implementation, we would like to open > discussion on this very small RFC to allow `readonly` on backed properties > even if they have a hook defined. > > https://wiki.php.net/rfc/readonly_hooks > > --

Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

> > However, I watched that RFC: https://wiki.php.net/rfc/strtolower-ascii > and https://github.com/php/php-src/pull/7511, > Perhaps, I should not locale-dependant for grapheme functions. Note that this RFC was about making the functions independent from the global mode as set by `setlocale()`.

Re: [PHP-DEV][DISCUSSION] grapheme_* functions adds locale in parameter (or any?)

> Le 5 juin 2025 à 03:04, youkidearitai a écrit : > > Hi, Internals > > I would like adds locale parameter that already there are grapheme_* > functions. > Because Unicode is locale-dependency but grapheme_* functions is not > locale-dependency. > > For example, Add $locale parameter is bel

Re: [PHP-DEV] Allowing class properties to remain Uninitialized as a default value.

> Le 3 juin 2025 à 06:22, Bradley Hayes a écrit : > > Uninitialized properties are really useful. > Being skipped in foreach loops and JSON encoded results and other behaviours > around uninitialized properties save a lot of time wasted on basic checks and > uncaught logical mistakes around n

Re: [PHP-DEV] ext/gd: changing signatures for functions returning true

> Le 27 mai 2025 à 00:51, David CARLIER a écrit : > > Hi, > > Working through this https://github.com/php/php-src/pull/18651/files, do not > mind waiting for PHP 9 if needs be. Let me know what you think. > > Cheers. Hi, Those functions are documented to return false on failure (e.g. http

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

> Le 5 avr. 2025 à 17:51, Niels Dossche a écrit : > > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels Hi, I think that this argument is not convincing, and even counterproductive:

Re: [PHP-DEV] [RFC] [Discussion] array_first() and array_last()

> Le 5 avr. 2025 à 17:51, Niels Dossche a écrit : > > Hi internals > > I'm opening the discussion for the RFC "array_first() and array_last()". > https://wiki.php.net/rfc/array_first_last > > Kind regards > Niels Hi Niels, It is reasonable. I have a userland implementation of that in my c

Re: [PHP-DEV] [RFC brainstorm] Approximately equals operator

> Le 1 avr. 2025 à 00:03, Niels Dossche a écrit : > > Hi internals! > > I'm excited to share what I've been working on! > I had an epiphany. I realized what we truly need to revolutionize PHP: a new > operator. > > [...] > First of all, if `$a == $b` holds, then `$a ~= $b` obviously. > The t

Re: [PHP-DEV] RFC: short and inner classes

> Le 15 mars 2025 à 12:53, Rowan Tommins [IMSoP] a écrit > : > > > > On 14 March 2025 23:37:08 GMT, Rob Landers wrote: >> I could get behind `::`, but I feel that it introduces human ambiguity. I >> don't believe it would introduce compiler ambiguity, but as a human, I have >> to hope the

Re: [PHP-DEV] Empty subject in match and switch constructions

> Le 4 févr. 2025 à 10:34, Dmitry Derepko a écrit : > > Hi, Claude! > >> On Feb 4, 2025, at 11:44 AM, Claude Pache wrote: >> >> Hi, >> >> One issue to resolve is how to interpret: >> >> ```php >> $x = match { >>

Re: [PHP-DEV] Empty subject in match and switch constructions

> Le 4 févr. 2025 à 08:43, Dmitry Derepko a écrit : > > Hi, Larry! > >> On Feb 3, 2025, at 10:01 AM, Larry Garfield wrote: >> >> On Sun, Feb 2, 2025, at 7:40 AM, Ilija Tovilo wrote: >>> Hi Dmitrii >>> >>> On Sun, Feb 2, 2025 at 1:05 PM Dmitry Derepko wrote: >>> >>> https://wiki.php.net/rf

Re: [PHP-DEV] RFC: Marking return values as important (#[\NoDiscard])

> Le 30 janv. 2025 à 16:51, Tim Düsterhus a écrit : > > Hi > > Am 2025-01-30 10:02, schrieb Rowan Tommins [IMSoP]: >> I think it would be good to explore alternatives - for instance, I think C# >> has a reserved _ variable to assign discarded results to, but may be >> misremembering. > > A

Re: [PHP-DEV] [RFC] Static property asymmetric visibility

> Le 25 nov. 2024 à 17:52, Larry Garfield a écrit : > > Static property asymmetric visibility was left out of the original RFC, > because it seemed like it would be hard and of little use. Turns out, Ilija > found a way to make it easy. (Ilija is smart.) So here's a small RFC to add > av

Re: [PHP-DEV] [RFC] [Discussion] Error backtraces v2

> Le 5 déc. 2024 à 21:57, Eric Norris a écrit : > > Hello yet again internals, > > I'd like to formally propose a continuation of the original error > backtraces RFC (https://wiki.php.net/rfc/error_backtraces): > > https://wiki.php.net/rfc/error_backtraces_v2 > Hi, Would be reasonable to

Re: [PHP-DEV] Needs Feedback - Yield without value in reference generator function does not create notice

> Le 26 nov. 2024 à 01:49, aggelos bellos a écrit : > > Hello everyone, > > In this issue #16761 it was > verified that in the above code it should throw a notice for both yields: > ``` > error_reporting(E_ALL); > function &y() > { > yield null

Re: [PHP-DEV] Deprecate alternate switch case syntax?

> Le 20 nov. 2024 à 15:45, Theodore Brown a écrit : > > Hello Internals, > > I recently found out (after 15 years of being a PHP developer) that PHP > allows using a semicolon rather than a colon after case statements. [1] I.e.: > > Hi, For reference, previous discussion on the subject:

Re: [PHP-DEV] Make Closure covariant to callable

> Le 12 nov. 2024 à 14:53, Gina P. Banyard a écrit : > > Hello internals, > > Ondřej Mirtes (author of PHPStan) remarked to me in August that Closure is > not a subtype of callable. > The implementation of this is quite straight forward and can be seen on > GitHub. [1] > The question is if t

Re: [PHP-DEV] Asymmetric visibility is a BC break

> Le 9 oct. 2024 à 17:01, Valentin Udaltsov a > écrit : > > Hi, internals! > > Since writing https://externals.io/message/125740 I've realized that > the major problem with aviz is actually simple but fundamental. > > In PHP <=8.0 this code is valid for an object of any user class: > > ```ph

Re: [PHP-DEV] [GitHub #7913] Vulnerability due to insecure default values for session.cookie_secure and session.cookie_httponly

> Le 13 sept. 2024 à 16:13, etkaar a écrit : > > Hi! > > I've created this issue in January 2022 but it seems it wasn't noticed yet > (since you probably do watch the mailing lists more than GitHub): > https://github.com/php/php-src/issues/7913 > > Kind Regards, > etkaar Hi, * Defaulting `s

Re: [PHP-DEV] RFC: Deprecate json_encode() on classes marked as non-serializable

> Le 5 sept. 2024 à 18:03, John Coggeshall a écrit : > > > As per my previous email to the list, I have now created the official RFC to > deprecate calling json_serialize() on instances of classes marked with > ZEND_ACC_NOT_SERIALIZABLE. > > I would suggest we take a step back from this and

Re: [PHP-DEV] json_encode() and Generators / RFC Karma

> Le 30 août 2024 à 09:36, Philip Hofstetter a > écrit : > > Hello, > > In the aftermath of an internal refactoring of an internal code-base to turn > something eager into something more lazy using Generators, it occurred to me > that while PHP refuses to serialize() a Generator, accidenta

Re: [PHP-DEV] Should there be a `get_declared_enums()` function ?

> Le 17 août 2024 à 15:17, Larry Garfield a écrit : > > On Fri, Aug 16, 2024, at 7:53 PM, Juliette Reinders Folmer wrote: >> On 16-8-2024 17:01, Ayesh Karunaratne wrote: >>> I went ahead and created PR https://github.com/php/php-src/pull/15443 along >>> with tests, UPGRADE notice, etc. I thin

Re: [PHP-DEV] function autoloading v4 RFC

> Le 15 août 2024 à 17:27, Rob Landers a écrit : > >  > Hello internals, > > I've decided to attempt an RFC for function autoloading. After reading > hundreds of ancient (and recent) emails relating to the topic along with > several abandoned RFCs from the past, and after much review, I've

Re: [PHP-DEV] [Concept] Flip relative function lookup order (global, then local)

Hi, I propose the following alternative approach: * establish a restricted whitelist of global functions for which the performance gain would be noteworthy if there wasn’t any need to look at local scope first; * for those functions, disallow to define a function of same name in any namespace

Re: [PHP-DEV] Should PHP reserve a namespace for built-in classes?

> Le 25 juil. 2024 à 05:22, Nick Lockheart a écrit : > > 1. Could we have a global setting (maybe php.ini) that makes all built- > in functions (not built in classes) directly accessible in any > namespace? That is: > > // php.ini > AlwaysUseGlobalFunctions = yes > > Then: > // myclass.php >

Re: [PHP-DEV] [RFC] Improve language coherence for the behaviour of offsets and containers

> Le 4 juil. 2024 à 15:52, Gina P. Banyard a écrit : > > Hello internals, > > I would like to formally open the discussion on an RFC I've been working on > for the past year: > https://wiki.php.net/rfc/container-offset-behaviour > > As DokuWiki is a bit of a faff at times, the Markdown sourc

Re: [PHP-DEV] Breaking change of rounding behavior in PHP 8.4

> Le 12 juil. 2024 à 13:24, Christoph M. Becker a écrit : > > Hi all, > > there has been a "small" change in the rounding logic of > _php_math_round()[1] a couple of months ago. A respective ticket, > claiming the new behavior would be a bug[2] had been filed a while ago > without proper tria

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

Le 6 juil. 2024 à 03:22, Mike Schinkel a écrit :On Jul 5, 2024, at 1:11 PM, Claude Pache <claude.pa...@gmail.com> wrote:Le 25 juin 2024 à 16:36, Gina P. Banyard <intern...@gpb.moe> a écrit :https://wiki.php.net/rfc/deprecations_php_8_4* About strtok(): An exact replacement of `strto

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.4

> Le 25 juin 2024 à 16:36, Gina P. Banyard a écrit : > > Hello internals, > > It is this time of year again where we proposed a list of deprecations to add > in PHP 8.4: > > https://wiki.php.net/rfc/deprecations_php_8_4 > Hi, * For each deprecation, it would be nice to provide explicitly

Re: [PHP-DEV] [RFC] Property Hook improvements

> Le 3 juil. 2024 à 14:42, Rob Landers a écrit : > > On Wed, Jul 3, 2024, at 14:28, Claude Pache wrote: >> >> >>> Le 3 juil. 2024 à 11:54, Claude Pache a écrit : >>> >>> >>> 2. As for readonly, I think that the invariant it is s

Re: [PHP-DEV] [RFC] Property Hook improvements

> Le 3 juil. 2024 à 11:54, Claude Pache a écrit : > > > 2. As for readonly, I think that the invariant it is supposed to provide > should be enforced as strictly as possible. It means that `readonly` is only > acceptable if there is no `get` hook. Hi, One more thing, w

Re: [PHP-DEV] [RFC] Property Hook improvements

> Le 1 juil. 2024 à 19:02, Larry Garfield a écrit : > > Hi folks. As Ilija's been polishing off hooks to get the PR merged, we've > run into two small revisions that should make life better for all involved. > One is a performance improvement that requires a very slight error handling > be

Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript

> Le 27 juin 2024 à 09:41, Rob Landers a écrit : > >> >> PHP User Modules are php files that are brought into the runtime through a >> new parser that is able to generate faster and more concise runtime code by >> removing support for problematic features and imposing a strict mode by >> de

Re: [PHP-DEV] [RFC] Static class

> Le 24 juin 2024 à 01:10, Bilge a écrit : > > Hi Internals! > > I am pleased to present my first RFC: Static class > . > > This work is based on the previous discussion thread on this list of the same > name, and hopefully captured all the relevant de

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

> Le 20 juin 2024 à 13:08, Vincent de Lau a écrit : > > > > From: Gina P. Banyard > Sent: Wednesday, June 19, 2024 5:08 PM >> >> On Tuesday, 18 June 2024 at 17:37, Robert Landers >> wrote: >> >>> Hello internals, >>> >>> [...] >>> >>> What are your thoughts? >> >> As self-proclaimed l

Re: [PHP-DEV] [RFC] [discussion] Correctly name the rounding mode and make it an Enum

Hi, Naming is hard, for sure. Here is my review. I find the names mostly reasonable, except Round::PositiveInfinity and Round::NegativeInfinity. I will discuss Round::PositiveInfinity. First: > I've discussed this with Saki. In that case the `HalfEven` and `HalfOdd` > modes would also need t

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

Hi, > One thing is clear is that "strict types" may be a bit of poor word > choice and gives people a false sense of security that it is "safe" or > "more correct" when this obviously isn't true. Thus, I'd like to > propose, for PHP 9, simply renaming it from strict_types to > scalar_type_coercion

[PHP-DEV] Default value for readonly properties

Hi, As of today, readonly properties cannot have a default value: ```php class UltimateQuestion { readonly int $answer = 42; // Fatal error: Readonly property Question::$answer cannot have default value } ``` The rationale given in the original RFC (https://wiki.php.net/rfc/readonly_proper

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 5 juin 2024 à 16:28, Larry Garfield a écrit : > > On Fri, May 31, 2024, at 8:59 PM, Larry Garfield wrote: >> On Fri, May 31, 2024, at 5:45 PM, Claude Pache wrote: >>>> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : >>>> >>>> How

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : > > So we feel the best way forward is to make the following changes: > > * private(set) implicitly means "final". (You can declare it explicitly if > you want, but it isn't necessary.) > * Make readonly incompatible with aviz again. > > Th

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 31 mai 2024 à 18:08, Larry Garfield a écrit : > > However, this also brings up another interesting issue: readonly properties > (in 8.3) DO allow redeclaration, essentially adjusting the property scope > (the class that declares it) to make the visibility check pass. That is, the > defi

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 30 mai 2024 à 12:16, Vincent de Lau a écrit : > >> >> We went through a bunch of syntax variations last year, including "public >> private", "public:private", and "public private:set", plus a few others. >> In an RCV poll, public private(set) was the favorite. (See link at the end >> of t

Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2

> Le 30 mai 2024 à 17:07, Derick Rethans a écrit : > >> >> Now, if I define the property as public private(set) with similar >> intentions, to make sure that there is no way for external scope or >> extending classes scope to write to the property, while allowing >> reading from external sc

Re: [PHP-DEV] [RFC] [Discussion] Add openStream() to XML{Reader,Writer}

> Le 21 mai 2024 à 21:00, Matthew Weier O'Phinney a > écrit : >> (But again, I prefer that all those methods work on instances, as it was the >> case before PHP 8. They shouldn’t have been switched to >> static-but-broken-for-subclasses without discussion.) > > Fixing the existing ones would

Re: [PHP-DEV] [RFC] [Discussion] Add openStream() to XML{Reader,Writer}

> Le 18 mai 2024 à 01:13, Niels Dossche a écrit : > > On 22/04/2024 20:41, Niels Dossche wrote: >> Hi internals >> >> I'm opening the discussion for my RFC "Add openStream() to >> XML{Reader,Writer}". >> RFC link: https://wiki.php.net/rfc/xmlreader_writer_streams >> >> Kind regards >> Niels

Re: [PHP-DEV] Inconsistencies between parameter number and index when reflecting a method/function

> Le 2 mai 2024 à 14:48, Ollie Read a écrit : > > The question that is holding this PR back is should these methods be 1 > indexed, so that the provided position is consistent with the error messages, > or how a person would typically count, or should they be 0 indexed to remain > consistent

Re: [PHP-DEV] [RFC] [Discussion] Add openStream() to XML{Reader,Writer}

> Le 23 avr. 2024 à 21:23, Niels Dossche a écrit : > > On 22/04/2024 21:53, Larry Garfield wrote: >> On Mon, Apr 22, 2024, at 6:41 PM, Niels Dossche wrote: >>> Hi internals >>> >>> I'm opening the discussion for my RFC "Add openStream() to >>> XML{Reader,Writer}". >>> RFC link: https://wiki.p

Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions

> Le 4 avr. 2024 à 01:08, Kamil Tekiela a écrit : > > If there are no more comments, I would like to put this RFC to vote in > the next two days. Hi, 1. In session_start(), it is possible to override ini settings like that: ```php session_start([ 'use_cookies' => '1', 'use_only_cookies' =>

Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

> Le 4 avr. 2024 à 15:10, Kamil Tekiela a écrit : > > Why is passing extra arguments a problem at all? In a parallel perfect and boring world, it is not a problem. In our world, disallowing extra arguments have two advantages: * catching bugs; * allowing to add new optional parameters to an

Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

> Le 4 avr. 2024 à 15:03, Mark Trapp a écrit : > > On Thu, Apr 4, 2024 at 5:43 AM Pablo Rauzy wrote: > > I like this concept, but instead of introducing a new syntax, have you > considered leveraging attributes in the same way that PHP 8.3 > introduced #[Override]? > > #[Nonvariadic] > func

Re: [PHP-DEV] Allow properties to be defined on interface

> Le 28 mars 2024 à 16:03, Saki Takamachi a écrit : > > Therefore, I propose to allow public properties to be defined on the > interface (It does not matter whether it is read-only or not). > Hi, For information, the question of properties on interfaces is covered by the currently discu

Re: [PHP-DEV] [RFC idea introduce] The issue where the __callStatic magic method is not called when statically calling a public method.

> Le 28 mars 2024 à 03:29, 하늘아부지 a écrit : > > Hi. > > I would like to register an RFC on the following issue. > https://github.com/php/php-src/issues/13813 > > To summarize briefly, users expect that the `__callStatic` magic method will > be called in all cases when a method is not static wh

Re: [PHP-DEV] Proposal: AS assertions

> Le 22 mars 2024 à 16:18, Rowan Tommins [IMSoP] a écrit > : > > $optionalExpiryDateTime = $expiry as ?DateTimeInterface else > some_other_function($expiry); > assert($optionalExpiryDateTime is ?DateTimeInterface); // cannot fail, > already asserted by the "as" I think that the `is` operator

Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions

> > I hear you, but what about exit; ?! > Do not worry exit; is still supported! > It only requires a _tiny_ bit of dark magic to achieve this! > exit; would just be interpreted as a fetch to a constant, > so when attempting to access the undefined exit/die case-insensitive constant > we just nee

Re: [PHP-DEV] RFC Proposal : Allows calling non-static public methods through the __callStatic magic method instead of throwing an error.

> Le 17 févr. 2024 à 16:51, Larry Garfield a écrit : > > On Fri, Feb 16, 2024, at 7:56 PM, 하늘아부지 wrote: >> Hi. >> I'd like to propose an RFC, but I don't have the authority. >> Below is my suggestion. >> If you think this makes sense, please write an RFC for me. >> Sincerely. >> >> --

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

Hi, > > FWIW Python's `time.sleep` also works like this: > https://docs.python.org/3/library/time.html#time.sleep Python also implements the following: > If the sleep is interrupted by a signal and no exception is raised by the > signal handler, the sleep is restarted with a recomputed timeou

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

> Le 28 nov. 2023 à 21:47, Hans Henrik Bergan a écrit : > >> What is the migration path for legacy code that use those directives? > > The migration path is to convert the legacy-encoding PHP files to UTF-8. > Luckily this can be largely automated, here is my attempt: > https://github.com/divi

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

> Le 28 nov. 2023 à 20:56, Kamil Tekiela a écrit : > >> Convert your PHP source files to UTF-8. > > If the solution is as easy as just converting the encoding of the > source file, then why did we even need to have this setting at all? > Why did PHP parser support encodings that demanded the

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

> Le 28 nov. 2023 à 19:57, Hans Henrik Bergan a écrit : > > With the dominance of UTF-8 (a fixed-endian encoding), surely no new > code should utilize any of declare(encoding='...') / zend.multibyte / > zend.script_encoding / zend.detect_unicode. > I propose we deprecate all 4. Hi, What is t

Re: [PHP-DEV] Callable arguments cannot have default value

> Le 28 nov. 2023 à 00:59, Sergii Shymko a écrit : > > Hi, > > Wanted to bring up an inconsistent behavior of callable arguments compared to > arguments of other types. > Callable argument cannot have a default value (tested string or array types - > both are not permitted). > The same exact

Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties

> Le 23 nov. 2023 à 08:56, Rowan Tommins a écrit : > > On 23 November 2023 01:37:06 GMT, Claude Pache wrote: >> What you describe in the last sentence is what was initially designed and >> implemented by the RFC: https://wiki.php.net/rfc/typed_properties_v2 &

Re: [PHP-DEV] Re: [RFC][Discussion] Harmonise "untyped" and "typed" properties

> Le 22 nov. 2023 à 23:17, Rowan Tommins a écrit : > > I'm probably going to regret asking this, but is there some reason it works > that way? Is there any chance of changing it to just: > >> Typed properties start off as uninitialized. >> >> Once you've assigned a value, you can't go back t

Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties

> Le 21 nov. 2023 à 00:08, Rowan Tommins a écrit : > > I've revised the RFC; it now proposes to keep the implicit "= null" for > untyped properties, although I'm still interested in suggestions for other > strategies around that. Hi, If you really want untyped property not being implicitl

Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties

> Le 17 nov. 2023 à 14:53, Rowan Tommins a écrit : > > On 17 November 2023 13:30:42 GMT, Claude Pache wrote: >> >> Yes, except that an untyped (respectively `mixed`) property cannot be >> redeclared as `mixed` (resp. untyped) in a subclass. A small step in th

Re: [PHP-DEV] [RFC][Discussion] Harmonise "untyped" and "typed" properties

> Le 17 nov. 2023 à 11:47, Rowan Tommins a écrit : > > On 16 November 2023 21:38:48 GMT, Jakub Zelenka wrote: >> This sounds like a huge BC break. Probably bigger and a bit harder to fix >> than disallowing dynamic props. > > More common, maybe; but trivial to fix: add "=null" at the end of

Re: [PHP-DEV] [RFC] [Discussion] Change the edge case of round()

> Le 5 nov. 2023 à 08:31, Saki Takamachi a écrit : > Hi, > > It's almost been two weeks since I opened this discussion. If there are no > other opinions, I am thinking of starting a vote tomorrow or later. > > Regards. > > Saki Hi Saki, Reading the RFC, it is unclear for me what are the

Re: [PHP-DEV] Basic Type Alias

> Le 26 oct. 2023 à 21:23, Larry Garfield a écrit : > > App-wide aliases run into the autoloading problem. If the engine runs across > the add() function above, and "numeric" isn't defined, what can it do? > Currently, all it can do is trigger autoloading, which only works for > class-ish

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

Hi, > Le 5 oct. 2023 à 14:26, Saki Takamachi a écrit : > > In fact, I predict that many use cases will be covered by GMP. > > Still, I think that there may be cases where calculation functions like > mainframe BCD are required, such as when calculating money. > > I am unable to decide whethe

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

> Le 1 oct. 2023 à 14:35, Saki Takamachi a écrit : > > Hi, internals > > I would like to start the discussion for my RFC "Adding bcround, bcfloor and > bcceil to BCMath”. > https://wiki.php.net/rfc/adding_bcround_bcfloor_bcceil_to_bcmath > > Regards. > > Saki > -- > PHP Internals - PHP Runt

Re: [PHP-DEV] Apply strict_types to internal functions

ct_types? >> (name is up for bikeshedding ofc) >> >> On Tue, 29 Aug 2023 at 17:49, Claude Pache wrote: >> [...] > Hi Hans Henrik, The rule of the mailing list is to post your answer below the text you are answering to, and to strip the parts of the original message

Re: [PHP-DEV] Apply strict_types to internal functions

> Le 29 août 2023 à 15:19, Saki Takamachi a écrit : > >> Hi, >> >> The larger issue is that higher-order functions do not inherit the >> `strict_types` mode from its calling code, and this is not specific to >> internal functions. >> >> If you intend to change that for internal functions (

Re: [PHP-DEV] Apply strict_types to internal functions

> Le 29 août 2023 à 02:46, Saki Takamachi a écrit : > > Hello. > > I’m Saki Takamachi. > > Inspired by the issue below, I'm thinking of proposing this RFC. > https://github.com/php/php-src/issues/12055 > > As the documentation below states, PHP's internal functions currently ignore > stric

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

> Le 27 juin 2023 à 10:36, Claude Pache a écrit : > > > >> Le 26 juin 2023 à 17:06, G. P. B. a écrit : >> >> On Wed, 31 May 2023 at 13:08, G. P. B. wrote: >> >>> Hello internals, >>> >>> I would like to start the discus

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

> Le 26 juin 2023 à 17:06, G. P. B. a écrit : > > On Wed, 31 May 2023 at 13:08, G. P. B. wrote: > >> Hello internals, >> >> I would like to start the discussion about deprecating various remains >> from the now removed string code evaluated assertions functionality of >> assert(). >> >> The

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

> Le 26 juin 2023 à 17:05, G. P. B. a écrit : > > On Wed, 31 May 2023 at 23:20, Claude Pache <mailto:claude.pa...@gmail.com>> wrote: >> Although your RFC says that the `zend.assertions` ini setting has superseded >> `assert.active` for a while, the “official”

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

> Le 1 juin 2023 à 00:20, Claude Pache a écrit : > > Another point: Your RFC is missing `assert.quiet_eval`... > (In fact, it is probable that the `assert.quiet_eval` ini setting and the ASSERT_QUIET_EVAL constant have been removed in PHP 8, but that the documentation has not

Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code assertions

> Le 31 mai 2023 à 14:08, G. P. B. a écrit : > > Hello internals, > > I would like to start the discussion about deprecating various remains from > the now removed string code evaluated assertions functionality of assert(). > > The RFC is located on the wiki at the following address: > https:

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

Hi Máté, > Le 30 mai 2023 à 01:41, Máté Kocsis a écrit : > > Hi Claude, > >> The replacement methods for IntlCalendar::set() (namely >> IntlCalendar::setDate() and IntlCalendar::setDateTime()) must not have a >> return type of `void`, but `true`, like the original method, for the two >> foll

Re: [PHP-DEV] [RFC] Property hooks, nee accessors

> Le 8 mai 2023 à 23:38, Larry Garfield a écrit : > > Ilija Tovilo and I would like to offer another RFC for your consideration. > It's been a while in coming, and we've evolved the design quite a bit just in > the last week so if you saw an earlier draft of it in the past few months, I >

Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])

> Le 11 mai 2023 à 18:37, Tim Düsterhus a écrit : > > Hi > > I'm now opening discussion for the RFC "Marking overridden methods > (#[\Override])": > > > > RFC: Marking overridden methods (#[\Override]) > https://wiki.php.net/rfc/marking_overriden_methods > Hi Tim, One weakness of t

Re: [PHP-DEV] [RFC] [Discussion] Deprecate functions with overloaded signatures

> Le 27 avr. 2023 à 23:28, Máté Kocsis a écrit : > > Hi Internals, > > As you have possibly already experienced, overloaded signatures cause > various smaller and bigger issues, while the concept is not natively > supported by PHP. That's why I drafted an RFC which intends to phase out > the m

Re: [PHP-DEV] Proposal: magic constant '::name' for properties and methods etc. like '::class' is for classes/object

> Le 12 mai 2023 à 19:29, Lydia de Jongh a écrit : > > Hi, > > Lately I made a small object initializer/builder with php Attributes. > > 'Directly' accessing properties and methods of the class as a parameter in > an Attribute is not really possible. > You can do that for a class with: \path\

  1   2   3   >