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] 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] 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] 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] [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] New core autoloading mechanism with support for function autoloading

> Le 10 avr. 2023 à 14:17, G. P. B. a écrit : > > Hello Internals, > > Dan and I would like to propose a new core autoloading mechanism that fixes > some minor design issues with the current class autoloading mechanism and > introduce a brand-new function autoloading mechanism: > https://wiki.

Re: [PHP-DEV] Moving PHP internals to GitHub

Hi , You made some good points, but please, avoid including statements that are plainly false: it lessens your arguments. I am specifically thinking of: > - having to subscribe to a mailing list to even see the discussions Have you never heard about externals.io ? > - hav

Re: [PHP-DEV] Final anonymous classes

> Le 24 avr. 2023 à 12:28, Daniil Gentili a écrit : > > Hi all, > > I've submitted https://github.com/php/php-src/pull/11126 to add support for > final anonymous classes, though as noted by iluuu1994, it would probably make > more sense to just make all anonymous classes final by default, wh

Re: [PHP-DEV] Final anonymous classes

> Le 25 avr. 2023 à 15:46, Nicolas Grekas a > écrit : > >  > Because they conceptually don't create a new type, I wonder if (final) > anonymous classes could be allowed to extend final classes? In order to not > allow hacking around and still create a type with class_alias(), we should > for

Re: [PHP-DEV] Proposal: native decimal scalar type support

> Le 27 avr. 2023 à 00:03, Rowan Tommins a écrit : > >> >> In PHP8, passing float values >> to BCMath may lead to issues due to type mismatch which is a >> mind-blowing counter-intuitive issue. > > Far from counter-intuitive, that's an essential feature of any decimal > implementation - as s

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\

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] 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] 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] 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] 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] 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 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 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 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] 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] 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

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] [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] [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] 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] 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] [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] 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 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] 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 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] 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] 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] 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 à 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] 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] 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] [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] 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] [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] 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: 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] 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] [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] [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] 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 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] [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] 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] 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 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 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 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

[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] 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

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"

> 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] 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] [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] 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] [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 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] 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] 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] 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] 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] 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] [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] [RFC] Saner string to number comparisons

> Le 27 févr. 2019 à 09:06, Kingsquare.nl - Robin Speekenbrink > a écrit : > > As of the 0 == "" bit: I do think that an empty string is widespread > regarded as falsey-string... Thus 0 == "" sould IMHO return true... > 0 == "" evaluating to true has been a footgun for me in the past; someth

Re: [PHP-DEV] [RFC] DOM Living Standard API

Beware that behaviour of some methods should differ between HTML and non-HTML documents. For instance, the RFC says: > DOMElement→nodeName casing was previously undefined, it is now changed to > always uppercase. However, the DOM Living Standard says it is uppercase (even, ASCII-uppercased) on

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 27 mars 2019 à 00:09, Benjamin Morel a écrit : > > - I would also strongly suggest that 2 strings are always compared > byte-by-byte; IMO it does (*somehow*) make sense that 42 == "42.0", but it > DOES NOT make sense that "42" == "42.0". (...) There are many ways to obtain numeric data

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 27 mars 2019 à 14:29, Benjamin Morel a écrit : > > Thinking about this a bit more, what about following JavaScript semantics? I > find them really good in this respect: > Arithmetic in JavaScript cannot be used reliably (in general) without converting your data to the proper type, beca

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 27 mars 2019 à 16:14, Benjamin Morel a écrit : > > > Sure, PHP has the huge advantage here to have a dedicated string > concatenation operator, removing any ambiguity around the + operator. This > does not mean that we cannot borrow their semantics for string/number > comparison! I wa

Re: [PHP-DEV] PHP_FLOAT_MIN is positive

> Le 3 avr. 2019 à 11:51, Benjamin Morel a écrit : > > Hi internals, > > I just used PHP_FLOAT_MIN for the first time, and was surprised that it is > the smallest **positive** number representable. Is this expected? > > This is unlike PHP_INT_MIN, which is the absolute smallest representable

Re: [PHP-DEV] Question about adding !function_identifier

> Le 3 avr. 2019 à 18:52, M. W. Moe a écrit : > > Hello, > > not documenting at first is not really a question of laziness or so, as > things are still moving around > you absolutely need this agility; a good design layout between theory and > stable state will refactored > discussed a thous

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> Le 5 avr. 2019 à 09:45, Stijn Peeters a écrit : > > Hi, > > If I understand correctly it is possible in this proposal to use normal > arguments after using an unpackable argument: > > $arr4 = array(...$arr1, ...$arr2, 111); //valid > > This is something that is not possible when usi

Re: [PHP-DEV] [RFC] Nullable Casting

> Le 8 avr. 2019 à 12:24, Stephen Reay a écrit : > > if your target ’type’ is `?int` and you pass an empty string, wouldn’t you > expect to get `null` rather than `0` ? You should get the same value than you get in: ```php declare(strict_types=0); function foo(?int $x) { return $x; }

Re: [PHP-DEV] [RFC] Nullable Casting

> Le 8 avr. 2019 à 07:05, David Rodrigues a écrit : > > And about "settype($variable, "?int")" it was requested on original mailing > by Claude Pache. PHP has several ways to perform casting: 1. (int) $foo 2. settype($foo, 'int'); 3. intval($foo) Th

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

> Le 10 avr. 2019 à 21:21, Stanislav Malyshev a écrit : > > Hi! > >> Inspired by Bob's recent RFC for concat precedence, I'd like to propose a >> deprecation and removal of the left-associative behavior of ternaries. >> Instead, explicit parentheses should be used: >> >> https://wiki.php.net

Re: [PHP-DEV] [RFC] Spread Operator in Array Expression v0.2

> Le 13 avr. 2019 à 11:09, Stijn Peeters a écrit : > > Is anyone aware of other arguments for not allowing normal arguments after > unpackable arguments in function calls? I've grabbed into the archives of internals. Apart from technical issues: The main argument against that affordance was

Re: [PHP-DEV] [RFC] Permit trailing whitespace in numeric strings

> Le 9 avr. 2019 à 12:47, Nikita Popov a écrit : > > On Thu, Apr 4, 2019 at 1:16 AM Andrea Faulds wrote: > >> Nikita Popov wrote: >>> I'm always a fan of making things stricter, but think that in this >>> particular case there are some additional considerations we should keep >> in >>> mind.

Re: [PHP-DEV] [RFC] Deprecate left-associative ternary operator

> Le 24 avr. 2019 à 11:10, Björn Larsson a écrit : > > Den 2019-04-22 kl. 10:09, skrev Nikita Popov: >> On Tue, Apr 9, 2019 at 11:54 AM Nikita Popov wrote: >> >>> Hi internals, >>> The only objection here came from Gabriel, and I don't think we'll come to >>> an agreement. >>> Inspired by Bo

Re: [PHP-DEV] Error instead of returning false

> Le 7 mai 2019 à 16:22, Gert a écrit : > > Hello internals, > > I wanted to propose an RFC, but i'd like to check first if this idea > has been considered before already. > > My idea, extremely summarized, would be to take the functions that > return false/null when they 'error', and instead m

Re: [PHP-DEV] Removing mysqlnd stats from phpinfo

> Le 17 mai 2019 à 09:35, Peter Bowyer a écrit : > > This could be a good time to make all blocks on the page collapsible, with > a "Collapse/Expand all" link added at the top. > > All added as progressive enhancement, so people with JavaScript disabled > see everything. There is no need for

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

> Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen a écrit : > > Greetings Internals > > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in P

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

> Le 21 juin 2019 à 20:15, Bishop Bettini a écrit : > > On Fri, Jun 21, 2019, 13:54 Claude Pache <mailto:claude.pa...@gmail.com>> wrote: > > > > Le 21 juin 2019 à 17:20, Kalle Sommer Nielsen > <mailto:ka...@php.net>> a écrit : > > > >

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

> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen a écrit : > > Hi > Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev > : >> My first question for many of those is - why? I.e. it deprecates a bunch >> of niche functions. Most people do not use these functions, so they >> probably don't

Re: [PHP-DEV] [RFC] Strict operators directive

> Le 26 juin 2019 à 08:50, Christian Schneider a écrit : > > Am 25.06.2019 um 15:09 schrieb Arnold Daniels : >> This RFC proposes a new directive 'strict_operators'. When enabled, >> operators may cast operands to the expected type, but must comply to; >> >> * Typecasting is not based on the

Re: [PHP-DEV] [RFC] Strict operators directive

> Le 26 juin 2019 à 11:36, Benjamin Morel a écrit : > >> (...) could be the case depending on a declaration somewhere else in the > source code. >> That's the confusion Claude and I were talking about: You cannot be sure > what a very simple line of code does. > > Oh, I see. You mean that onl

Re: [PHP-DEV] [RFC][VOTE] Deprecate curly brace syntax for accessing array elements and string offsets

> Le 3 juil. 2019 à 17:59, Nikita Popov a écrit : > > On Wed, Jul 3, 2019 at 4:41 PM Levi Morrison wrote: > >> Was any analysis of usage done for top open source projects? I support >> this direction, but would prefer to know its current impact before >> voting. >> > > I checked top 2k pro

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

The deprecation RFC lists `apache_request_headers()`, because it is “an Apache-specific name is also available in other SAPIs, even though it is also available under the SAPI-independent name getallheaders()”. Have you ever thought about making a more thorough and consistent change with other s

Re: [PHP-DEV] Re: [VOTE] Voting opens for str_starts_with and ends_with functions

> Le 8 juil. 2019 à 15:20, Christoph M. Becker a écrit : > > FTR, there is already substr_compare(). `substr_compare()` (as well as `strncmp()` which I am currently using in lieu of `str_starts_with()`) forces you to provides the substring and the length of the substring, instead of just the

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

> Le 9 juil. 2019 à 09:40, Peter Bowyer a écrit : > > On Mon, 8 Jul 2019 at 19:09, Björn Larsson > wrote: > >> Having this _ci postfix is a new way of indicating case insensitivity. >> I think that it might add to negative votes. Personally I think it's a >> good idea to mimic existing ways

Re: [PHP-DEV] [VOTE] Strict operators directive

> Le 9 juil. 2019 à 12:09, Andreas Heigl a écrit : > > > > Am 09.07.19 um 12:06 schrieb Christian Schneider: >> Am 09.07.2019 um 11:30 schrieb Marco Pivetta : >>> I wasn't sure about the full implications of this, but after some thought, >>> the worst that can happen is excessive strictness,

Re: [PHP-DEV] [VOTE] Deprecations for PHP 7.4

> Le 8 juil. 2019 à 21:27, Nikita Popov a écrit : > > Hi internals, > > I've opened voting on the deprecations for PHP 7.4 RFC: > https://wiki.php.net/rfc/deprecations_php_7_4 > > As usual, each deprecation has it's own vote and requires its own, > independent 2/3 majority to pass. Voting clos

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

> Le 8 juil. 2019 à 18:52, Andrey Andreev a écrit : > > Hi, > > On Mon, Jul 8, 2019 at 4:54 PM Claude Pache <mailto:claude.pa...@gmail.com>> wrote: >> >> >>> Le 8 juil. 2019 à 15:20, Christoph M. Becker a écrit : >>> >>>

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

> Le 23 juil. 2019 à 19:54, G. P. B. a écrit : > > The only point of contention of this RFC that I potentially see is the > removal in PHP 8.1 after short open tags being a Parse Error in PHP 8.0 > instead of it being removed in PHP 9 after it having had a whole major > version release cycle. R

Re: [PHP-DEV] Stop replacing dots with underscores in query, post andcookie parameters for PHP 8?

> Le 24 juil. 2019 à 00:52, Stanislav Malyshev a écrit : > > Hi! > >> My preferred solution would be to add a new built-in function that >> re-does the mangling exactly as it used to be done. It would be no great >> maintenance burden on us to maintain such a function for the future, but >> it

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

> Le 28 juil. 2019 à 21:12, Marco Pivetta a écrit : > > On Sun, Jul 28, 2019 at 9:06 PM Stanislav Malyshev > wrote: > >> Hi! >> >>> Nah, by-ref is pretty much avoided in OSS packages, but we can surely >>> survey the ecosystem to verify this. >> >> I literally work with code that uses refe

  1   2   3   >