Am 01.10.2025 um 11:01 schrieb Alexandre Daubois :
> There is currently no way of knowing if a regex pattern is valid, apart from
> writing clunky code. [2]
>
> Two propositions emerged from the issue: either create a dedicated
> "preg_validate()" function, or add a new flag to "filter_var()", n
Am 16.09.2025 um 13:45 schrieb Alexandre Daubois :
> I’d like to present this new RFC. When discussing the issue, we first thought
> that the RFC process wasn’t necessary. However, discussions on the PR showed
> that selecting new letters for pack and unpack is more challenging than we
> initial
Am 18.08.2025 um 15:36 schrieb Rowan Tommins [IMSoP] :
> A developer coming to PHP from any combination of JavaScript, Perl, C#, Java,
> VisualBasic, Python, Ruby, Swift, Elixir, Dart, Rust, even Excel ... is going
> to look first for a function called "split" or some variation of that. If
> the
Am 04.08.2025 um 17:23 schrieb Larry Garfield :
> Hi folks. I recently wrote a blog post on behalf of the PHP Foundation about
> some work Gina has been doing regarding generics. It's a follow-up to last
> year's post on a similar topic. We are especially looking for feedback from
> the Inter
Am 31.07.2025 um 17:53 schrieb Rowan Tommins [IMSoP] :
> On 31/07/2025 14:46, Christian Schneider wrote:
>>> $fh = try fopen($filePath, 'w') ignore (FileLockedException);
>>>
>> First of all: I'm wary because partial error handling seems dangerous to mel
Am 31.07.2025 um 13:16 schrieb Rowan Tommins [IMSoP] :
> I think an inline syntax like this would be a powerful feature, and a
> potential replacement for the @ operator:
>
> $fh = null;
> $fh = try fopen($filePath, 'w') ignore (FileLockedException);
First of all: I'm wary because partial error
Am 31.07.2025 um 09:10 schrieb Rob Landers :
> I can see something like this being useful in niche applications. For
> example, I have a proxy generation class that creates something like this:
>
> public function remoteCall() {
> $this->operation = nameof($this->remoteCall(...));
> $this->ar
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!
Am 26.06.2025 um 14:04 schrieb Gina P. Banyard :
> On Monday, 2 June 2025 at 17:11, Gina P. Banyard wrote:
>
>> Hello internals,
>>
>> This is the first RFC out of a set of type system related RFCs I want to
>> propose for PHP 8.5.
>> It also used the recently enabled Markdown support on the wi
Am 25.06.2025 um 12:37 schrieb Gina P. Banyard :
> While working on the deprecation to/from bool type juggling in functions RFC
> and seeing the impact within Symfony, we found a common slightly annoying
> case.
> The getDocComment method of various Reflection classes was always used as a
> stri
Am 10.06.2025 um 21:46 schrieb Hans Henrik Bergan :
> Can we make str_(starts|ends)_with variadic?
> ```
> if (str_starts_with($url, "http://";, "https://";)) {
>// url
> }
> if (str_ends_with($filename, ".pdf", ".doc", ".docx")) {
>// document
> }
> if(str_ends_with($str, ...$validExtensi
Am 27.05.2025 um 10:00 schrieb Claude Pache :
>> Le 27 mai 2025 à 00:51, David CARLIER a écrit :
>> 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.
>
>
> Those functions are documented to return fals
Am 08.05.2025 um 00:36 schrieb Gina P. Banyard :
>> If this would have been done without warning phase then it would be a
>> blocker for upgrading to PHP 8.4, now filtering this warning is enough while
>> the packages are being updated.
>
> Comparing a core language change to be the same level a
Am 27.04.2025 um 20:22 schrieb Gina P. Banyard :
> I fundamentally reject the concept of this RFC to restrict our ability to do
> input validation.
I am sorry but I fail to see how the RFC restrict the ability to do input
validation.
> Emitting an E_DEPRECATED for invalid inputs remains utter n
Am 11.03.2025 um 16:29 schrieb Christian Schneider :
> ...(if you want to be strict about warnings then just convert them to an
> exception, that's easy enough)...
Reading it back I maybe wasn't clear: I mean if you as an application developer
want to be strict then you can use
Am 11.03.2025 um 12:54 schrieb Gina P. Banyard :
> Taking the example of ext/pcntl again, if it were a standalone extension,
> having it follow semver is a way more reasonable proposition.
> Because we could just release 2 versions the same day, a x.y+1.0 introducing
> a warning, and a x+1.0.0 wh
Am 11.03.2025 um 07:32 schrieb Gina P. Banyard :
> On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
>> I’d like to align on the approach to validating arguments for built-in
>> functions (usually for flag inputs). Some ongoing discussions in PRs:
>> - https://github.com/php/php-src/pull/15647
Am 29.01.2025 um 21:16 schrieb Rob Landers :
> On Wed, Jan 29, 2025, at 20:50, Tim Düsterhus wrote:
>> The `(void)` cast makes the intent of not being interested in the return
>> value clear. In C casting to `(void)` is an established pattern of
>> "using" a value that the compiler would otherwis
Am 29.01.2025 um 04:20 schrieb David CARLIER :
> Working on this PR #17440, I wanted to ask if the BC from these two calls
> were ok because :
>
> Before
> function socket_getsockname(Socket $socket, &$address, &$port = null):
> bool {}
>
> After
> function socket_getsockname(Socket
Am 02.12.2024 um 13:31 schrieb Rowan Tommins [IMSoP] :
> On 01/12/2024 23:50, mickmackusa wrote:
>> I can appreciate that. Going forward, is there any benefit to preserving
>> the behavior of returning integers beyond -1, 0, and 1?
>> Should these topically related functions receive a new last ar
Am 14.11.2024 um 22:27 schrieb Gina P. Banyard :
> Agreed, this bites us constantly when needing to reason about what an
> "object" is in PHP.
> Similar to array it mixes the concept of a struct, with that of a reference
> value, and "overloading" various behaviours (e.g. iterators and ArrayAcces
Am 14.11.2024 um 10:59 schrieb Marco Pivetta :
> On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote:
>> Hello, Internals!
>>
>> As you know if you try to unpack a regular object (`...$object`) you will
>> get an error: Only arrays and Traversables can be unpacked.
>> I don't really see a reason for this
Am 14.09.2024 um 17:33 schrieb Gina P. Banyard :
> I came across the Directory class while doing some code exploration of
> ext/standard.
> This class is effectively an opaque object for Directory resources, however
> it doesn't behave like one, as it has existed since PHP 4.
>
> As such, I am p
Am 23.08.2024 um 12:27 schrieb Rob Landers :
> On Fri, Aug 23, 2024, at 12:14, Christian Schneider wrote:
>> Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
>> > I think we are all trying to achieve the same thing here.
>>
>> I'm not sure who "we" and
Am 23.08.2024 um 11:34 schrieb Nick Lockheart :
> I think we are all trying to achieve the same thing here.
I'm not sure who "we" and what "same thing" here exactly is.
I recall the following arguments for changing the current situation about
function look ups:
- Performance
- Function autoloadi
Am 21.08.2024 um 09:44 schrieb Faizan Akram Dar :
> On Wed, Aug 21, 2024, 9:34 AM Christian Schneider
> wrote:
>> The point where I think we disagree is that it improves the code. It may
>> improve performance of the code (even though I somewhat doubt this has a
>> *sig
Am 20.08.2024 um 17:14 schrieb Levi Morrison :
> Keep in mind that qualifying
> every global function is annoying but probably can be somewhat
> automated, and will bring better performance. So again, this improves
> the existing code even without upgrading.
Just to be sure: Would code *not* using
Am 16.08.2024 um 22:16 schrieb Kris Craig :
> On Fri, Aug 16, 2024 at 8:11 AM Derick Rethans wrote:
>
>> You have therefore been given a 3-month timeout, which will be enforced
>> by blocking you from sending email to the php.net domain, including
>> subdomains.
>>
> This message kinda freaked
Am 04.04.2024 um 08:29 schrieb Saki Takamachi :
> I added some examples, corrected incorrect explanations, etc. Now that the
> specifications have been fairly finalized and the RFC has been clarified, I
> would like everyone to check it out again.
>
> https://wiki.php.net/rfc/support_object_type
Am 30.03.2024 um 16:35 schrieb Daniil Gentili :
>> That would break lots of tools as it requires extra dependencies so it is
>> not something that would could in stable versions.
> Btw, I do not believe that "it would require end users to install autotools
> and bison in order to compile PHP from
Am 09.03.2024 um 08:18 schrieb Marc :
> As the pseudo type `mixed` exists since PHP 8.0, which is already
> out-of-date, I have the feeling it would be better to force people to
> explicitly write `mixed` to widen the type of an overwritten function and let
> "no type" inherit the argument and r
Am 26.02.2024 um 14:25 schrieb Daniil Gentili :
> I really don't think that a modern discussion system can afford to randomly
> loose messages: mailing lists should not be used in 2024.
Just because Gmail decided to tighten the rules about SPF/DKIM just now does
not mean email is broken or loses
Am 26.02.2024 um 10:56 schrieb Daniil Gentili :
>> gmail is failing to send emails to the list (hence why it has probably been
>> a bit quite around here). Here is the error:
> +1, personally I would just switch to github issues and discussions, even
> ignoring all the deliverability issues, I do
Am 20.11.2023 um 22:00 schrieb Lanre Waju :
> I will have to disagree with everything you said:
Side-note: This is IMHO not a good intro into a discussion ;-)
> I outlined what a static class would be: A class that cannot be instantiated
> in which all members are implicitly static. We already h
Am 18.10.2023 um 18:42 schrieb Larry Garfield :
> So the real question is: Would anyone who voted No on operator overloading
> before vote Yes on it if it used ~=, ~>, ~+, etc. instead?
I confess that I'm not a fan of operator overloading for a language like PHP
but introducing new operators on
Am 18.10.2023 um 10:42 schrieb Daniil Gentili :
> This is precisely why I'm planning to submit the RFC to make the change in
> PHP 8.4, which is when the new JIT will be introduced.
Ah, I missed that part, my bad. I'd suggest mentioning this in the RFC.
I also went back Dmitry's RFC and saw that
Am 17.10.2023 um 19:39 schrieb Daniil Gentili :
> I would like to submit an RFC (and related PR) to deprecate posix_times for
> PHP 8.4, removing it for PHP 9.
My question here would be: Is there sufficient reason to remove this function
and introduce a BC break, i.e. is the implementation code
Am 17.10.2023 um 19:46 schrieb Daniil Gentili :
> I would like to submit an RFC and PR to change a few INI defaults for
> opcache, changing how JIT is disabled by default.
>
> Currently, JIT is disabled by default using the |opcache.jit_buffer_size=0|
> default, instead of |opcache.jit=0|.
>
>
Am 15.10.2023 um 19:24 schrieb Tim Düsterhus :
> Making getFloat(float $min = 0.0, float $max = 1.0, IntervalBoundary
> $boundary = IntervalBoundary::ClosedOpen) would seemingly make it legal to
> call ->getFloat(0.5), which I consider to be worse than nextFloat().
While I understand that you fi
Am 05.06.2023 um 19:59 schrieb Niels Dossche :
> I'm opening the vote now on my proposal to include mb_str_pad() into PHP 8.3.
> RFC link: https://wiki.php.net/rfc/mb_str_pad
I voted "No" because I think it should be grapheme_str_pad instead and I'd like
to avoid having both the mb_ and grapheme_
Am 12.04.2023 um 15:52 schrieb Alex Wells :
> PHP currently uses internals@lists.php.net for communication. That includes
> mostly RFCs (or their votings, or their pre-discussion) and sometimes
> questions about the implementation or possible bugs.
>
> While emailing definitely works, it's not the
Am 30.03.2023 um 10:50 schrieb Lynn :
> That said, mailing lists are ancient and in my opinion a horrible way of
> doing things.
Mailing lists have been around for a long time, yes, but it also means the way
we use it for larger scale communication has been refined over time. Please
consider th
Am 29.03.2023 um 11:55 schrieb Tim Düsterhus :
> On 3/29/23 11:42, Sebastian Bergmann wrote:
>> Am 29.03.2023 um 11:31 schrieb Rokas Šleinius:
>>> I wouldn't say removing the final attribute from enums actually "breaks"
>>> any functionality.
>> I am with Marco on this: removing the "finality" fro
Am 28.03.2023 um 14:42 schrieb G. P. B. :
> On Tue, 28 Mar 2023 at 08:19, Christian Schneider
> wrote:
>> There are two cases I would handle differently:
>> - I'm not sure why a negative step for $start > $end is considered wrong, I
>> consider range(10, 0, -2)
Am 28.03.2023 um 00:22 schrieb Larry Garfield :
> On Mon, Mar 27, 2023, at 2:12 PM, Mel Dafert wrote:
>> On 27 March 2023 20:20:58 CEST, "Michał Marcin Brzuchalski"
>> wrote:
>>> Personally, I'd like the unserialize to throw an exception if trailing
>>> bytes are detected.
>>> If not by default
Am 28.03.2023 um 00:36 schrieb G. P. B. :
> I therefore propose the "Define proper semantics for range() function" RFC
> to address the unintuitive behaviour that sees no usage and/or hide bugs:
> https://wiki.php.net/rfc/proper-range-semantics
>
> The change propose to throw TypeErrors and ValueE
Am 10.03.2023 um 20:04 schrieb Eugene Sidelnyk :
> Another simplified example:
>
> ```
> // partial application
> foo(bar(1, ...));
While it is not as concise as your version I think the work-around with short
arrow functions works ok unless your code is full of partial applications:
foo
Am 01.03.2023 um 01:13 schrieb Bob Weinand :
> In this case, while the primary concern of the RFC was rejected, I think it's
> pretty clear, that there was a supermajority for something specific.
I didn't vote on this RFC but I have to disagree with you and Max here: My
understanding of such a v
Am 28.02.2023 um 22:04 schrieb Max Kellermann :
> On 2023/02/28 21:16, Dmitry Stogov wrote:
>> Recently we voted for inluce cleanup RFC
>> https://wiki.php.net/rfc/include_cleanup and it was declined.
>
> Which specific commits do you wish to revert? Is this about include
> cleanups (none of w
Am 24.01.2023 um 09:55 schrieb Máté Kocsis :
> We've just opened the vote for the "Readonly amendments" RFC, which is
> going to be open for 2 weeks (until 2023-02-07).
>
> Link: https://wiki.php.net/rfc/readonly_amendments
> Discussion: https://externals.io/message/119007
I like the idea of more
> Am 18.01.2023 um 23:29 schrieb Larry Garfield :
> On Tue, Jan 17, 2023, at 1:25 PM, Jesse G. Donat wrote:
>> I'm looking to measure reaction to a proposal.
>>
>> My proposal is to have the STDOUT and STDERR global constants always
>> defined rather than just when running via CLI.
>
> Does any
Am 18.01.2023 um 16:26 schrieb Claude Pache :
>> Le 18 janv. 2023 à 16:20, Derick Rethans a écrit :
>>
>> if (version_compare(phpversion(), "8.4.0", ">")) {
>> setcookie("test", "value", samesite: SameSite::Stricter);
>> } else {
>> setcookie("test", "value", samesite: SameSite::Strict);
>> }
>
Am 17.01.2023 um 15:59 schrieb G. P. B. :
> Side-Note: Isn't SameSite a very generic name in the global namespace? I'm
> not sure what the PHP policy is here.
>
> AFAIK the global namespace is "owned" by PHP so that shouldn't be an issue
> per the usual policy.
In a quick check I could not find
Am 16.01.2023 um 14:39 schrieb G. P. B. :
> On Sun, 15 Jan 2023 at 20:58, Christian Schneider
> wrote:
> Some comments:
> - I am not convinced that we should introduce a third way of providing
> parameters to setcookie(). I don't think this function is used often enough
>
Am 14.01.2023 um 16:14 schrieb G. P. B. :
> I would like to start the discussion about the Add SameSite cookie
> attribute parameter RFC:
> https://wiki.php.net/rfc/same-site-parameter
>
> This proposes to add an optional same site parameter to the setrawcooki(),
> setcookie() and session_set_cook
Am 11.01.2023 um 17:09 schrieb Christoph M. Becker :
> On 11.01.2023 at 15:19, Christian Schneider wrote:
>
>> Am 11.01.2023 um 15:04 schrieb Christoph M. Becker :
>>> On 11.01.2023 at 14:07, Christian Schneider wrote:
>>>
>>>> While migrating to
Am 11.01.2023 um 15:04 schrieb Christoph M. Becker :
> On 11.01.2023 at 14:07, Christian Schneider wrote:
>
>> While migrating to PHP 8.2 we noticed the change in strtotime.
>> PHP <= 8.1 supported "today +- 3 days" etc. but the support for multiple
>> sign
While migrating to PHP 8.2 we noticed the change in strtotime.
PHP <= 8.1 supported "today +- 3 days" etc. but the support for multiple sign
characters (++, --, -+, +-) has been removed in 8.2:
https://3v4l.org/mHa3t
This was discussed at
https://github.com/php/php-src/issues/9950
Am 24.10.2022 um 04:56 schrieb BohwaZ :
> I am proposing that the SQLite3 extension stops using warnings for
> errors and instead throws exceptions by default:
>
> https://wiki.php.net/rfc/sqlite3_exceptions
>
> Whether we just deprecate warnings first and default to exceptions, and
> then remove
Am 11.10.2022 um 07:09 schrieb MKS Archive :
>> On Oct 10, 2022, at 8:04 PM, David Gebler wrote:
>>
>> This is what's bothering me. Either these "experimental" features have
>> passed RFC and will be part of the language, as you've said above, or
>> they're actually experimental i.e. not finalize
Am 06.10.2022 um 23:40 schrieb David Rodrigues :
> But keep in mind that these features are already intended for PHP, and it
> is not a "feature test" or suggestion. The voting process is mandatory and
> the feature must already be set to "accepted".
Just so I understand what you are saying: You w
Am 05.10.2022 um 15:38 schrieb Alex Wells :
> Advantages of experimental features over extensions:
> - they allow changes to the parser
> - they are universally supported (by IDE's, parsers etc) because they are
> part of a stable language release, not an unpopular/unknown extension
> - usages of t
Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> What I can see is two noble, but conflicting ideals:
> 1/ sort() and ksort() should be consistent about their sorting algorithms.
> I think we can all agree about that in the ideal case, at least.
> 2/ Behavior within a minor release should be self-co
Am 26.08.2022 um 14:19 schrieb Christoph M. Becker :
> On 26.08.2022 at 05:15, Go Kudo wrote:
>
>> In the actively supported version of PHP, `ksort()` has been modified to
>> include BC Break.
>>
>> https://github.com/php/php-src/issues/9296
>>
>> This may seem like an appropriate bug fix, but i
Am 11.08.2022 um 11:03 schrieb Alex Wells :
> That’s just a concept. I’d love to bring a lot more examples in an RFC if
> there’s more positive than negative feedback. Again, I’m more looking for
> feedback than trying to convince someone, but I’ll showcase a couple real
> comparisons for some c
Am 26.04.2022 um 15:16 schrieb Andreas Leathley :
> On 26.04.22 14:47, Christian Schneider wrote:
>> There are two big reasons:
>> - BC: Checking for the truthiness of a value is very common and would
>> require a lot of code changes.
>> - Some of us like the concisen
Am 26.04.2022 um 11:54 schrieb Andreas Leathley :
> I have not found any past proposals or discussions to change boolean
> coercions, so I would like to find out how the thoughts on internals are
> to change this, or if there are any reasons not to change this that I
> have not thought of.
There a
Am 21.04.2022 um 16:09 schrieb Rowan Tommins :
> All of that, and the "consistency" in the title of your RFC, is a complete
> distraction from the real questions:
>
> 1) given a null input, and a non-nullable parameter, what should the
> run-time do?
> 2) what is the best way to help users update
Am 24.03.2022 um 10:32 schrieb Rowan Tommins :
> On 23/03/2022 23:39, Juliette Reinders Folmer wrote:
>>
>> While I agree the functions are often used incorrectly, what worries me
>> about this RFC is that the only viable alternatives for these functions are
>> in two optional extensions, which
Am 22.03.2022 um 16:14 schrieb Sara Golemon :
> So while I said I wanted to avoid the firestorm suggesting userspace
> overloading would bring, maybe that's the question to ask:
>
> Who's just a hard-nope on userspace operator overloading? If your reasons
> go beyond foot-gun (and that is a valid
Am 16.03.2022 um 11:39 schrieb Mark Randall :
> On 16/03/2022 09:17, Christian Schneider wrote:
>> Maybe we should ask ourselves the question: Why would the entire package be
>> blocked? Just because it is too big or maybe there *are* subtleties which
>> have not b
Am 16.03.2022 um 10:00 schrieb Mark Randall :
> On 15/03/2022 23:02, Patrick ALLAERT wrote:
>> I am not against the fact this warning becomes an error per se. I am just
>> not very fan of cherry-picking an individual kind of problem (read:
>> notice/warning/error/...) and changing it without a more
Am 16.03.2022 um 06:52 schrieb Juliette Reinders Folmer
:
> I've just been looking in detail at the Partially Supported Callables
> deprecation RFC:
> https://wiki.php.net/rfc/deprecate_partially_supported_callables
>
> The RFC explicitly excludes the `is_callable()` function and the `callable`
Am 15.03.2022 um 20:07 schrieb Miguel Rosales :
> Christoph M. Becker wrote on 15/3/22 19:17:
>> That explicitly excludes undefined array indexes, and apparently also
>> excludes undefined properties (which raise "Warning: Undefined property:")
>>
> AFAIU error promotion for undefined properties h
Am 03.03.2022 um 10:11 schrieb Kalle Sommer Nielsen :
> Den tor. 3. mar. 2022 kl. 10.48 skrev Sergey Panteleev
> :
>>
>> I'd suggest making a PR with the News (press release) in web-php
>> and maybe discussing it already on GitHub,
>> since it would get more coverage and we can hear more opinions
Am 01.03.2022 um 11:43 schrieb Christoph M. Becker :
> On 28.02.2022 at 23:11, Christian Schneider wrote:
>
>> Am 28.02.2022 um 22:05 schrieb Christoph M. Becker :
>>
>>> On 28.02.2022 at 21:51, Craig Francis wrote:
>>>
>>>> And after all o
Am 28.02.2022 um 22:05 schrieb Christoph M. Becker :
> On 28.02.2022 at 21:51, Craig Francis wrote:
>
>> And after all of this, no-one has come up with a way to find or address
>> this problem, e.g.
>>
>> > $nullable = ($_GET['a'] ?? NULL);
>> echo htmlentities($nullable);
>> ?>
>
> function
Am 07.02.2022 um 13:07 schrieb G. P. B. :
> On Mon, 7 Feb 2022 at 09:34, Christian Schneider <mailto:cschn...@cschneid.com>> wrote:
> > If a parameter expects a string, that is what it should be given, and its
> > the callers' responsibility to ensure that is the cas
Am 07.02.2022 um 09:35 schrieb Mark Randall :
> On 07/02/2022 01:27, Craig Francis wrote:
>> I know one person simply said this was a "terribl > idea", but I'm still
>> waiting to hear any details on why.
>
> I understand your motivations in proposing them, but to my mind it goes
> against the di
Am 30.01.2022 um 16:55 schrieb Nikita Popov :
> Something I want to add here is that there is also an important technical
> motivation behind promoting undefined variable notices to exceptions: The
> big problem with these (from a pure implementation perspective) is that we
> need to throw the warn
Am 29.01.2022 um 20:03 schrieb Mark Randall :
> On 29/01/2022 16:33, Christian Schneider wrote:
>> If a static analyzer manages to catch it at development time then that is a
>> lot better.
>
> Of course it's better, but you wouldn't argue that a car doesn't n
Am 28.01.2022 um 23:57 schrieb Jordan LeDoux :
>
> On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider <mailto:cschn...@cschneid.com>> wrote:
>
> My issue with this is that while it seems to work towards the goal of "fail
> fast" it does not completely fulf
Am 27.01.2022 um 23:41 schrieb Mark Randall :
> What we don't want to do, I think, is end up in a situation like JS where it
> has to be opted in: https://www.w3schools.com/js/js_strict.asp
That's why the majority decided a while ago that you don't have to opt-in right
now: The default error_rep
Am 27.01.2022 um 05:17 schrieb Mark Randall :
> It is my firm believe that a language such as PHP should not be dependent on
> static analysers to protect users against engine-level problems that may
> occur during runtime.
My issue with this is that while it seems to work towards the goal of "f
Am 26.01.2022 um 17:42 schrieb Craig Francis :
> While I did begin an RFC to allow *some* functions to be more tolerant of
> NULL, especially for those scripts not using `strict_types`:
>
> https://wiki.php.net/rfc/allow_null
>
> Or in other words, to "relax certain type requirements on a case by
Am 26.01.2022 um 16:55 schrieb Lynn :
> I don't want to waste time trying to figure out if an undefined `$j++` is a
> bug because it should've been `$i++`, or that `$i = 0;` is supposed to be
> unused because someone forgot to remove it. Given the legacy I work with,
> it's unrealistic to have s
Am 25.01.2022 um 00:47 schrieb Mark Randall :
> ** Undefined Variables Promoted to Error **
>
> PHP currently treats reading an undefined variable as though it were a null,
> emitting a warning message in the process. This was previously promoted from
> a notice in the PHP 8 engine warnings RFC.
Am 31.12.2021 um 03:21 schrieb Kirill Nesmeyanov :
> I support this behavior fix because in its current form, due to a similar
> problem (almost?), all PSR-7 implementations contain bugs that violate
> RFC7230 (section 3.2:
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus,
>
Am 02.12.2021 um 16:19 schrieb Sara Golemon :
> I would say that such applications should consider unifying their own
> types. $a = $_GET['q'] ?? ''; Is there a place in the application where
> empty string and null would have been distinct? i.e. Is a search for
> nothing different from not sear
Am 20.09.2021 um 10:36 schrieb Pierre :
> Le 20/09/2021 à 02:03, tyson andre a écrit :
>> I've created a new RFC https://wiki.php.net/rfc/deque to add a `final class
>> Deque`
>
> It seems that you are writing more than one RFC to add many data structures.
> I love that you're doing that, but I
Am 17.09.2021 um 10:43 schrieb Nikita Popov :
> The locale-sensitivity of strtolower() only works with legacy
> single-byte encodings and as such is of questionable usefulness even in
> cases where it is not actively harmful.
>
> That said, I do think this change requires an RFC.
I agree that thi
Am 17.09.2021 um 04:09 schrieb tyson andre :
> I've created a new RFC https://wiki.php.net/rfc/vector proposing to add
> `final class Vector` to PHP.
First of all: I don't have a strong opinion on a Vector class being useful or
necessary.
But I have two comments about this RFC:
1) Using the ve
Am 06.09.2021 um 18:08 schrieb Benjamin Morel :
> Yes, please! A future where dynamic properties are only allowed on
> DynamicObject is bright.
I have nothing against a DynamicObject alias for people who like to be more
explicit in their code...
> I would even deprecate the stdClass alias straig
Am 06.09.2021 um 16:46 schrieb Pierre Joye :
> Also as someone mentioned here afterwards, instead of removing it
> straight away, I would go with the flag first, less risky :)
Out of curiosity: Do you think disabling the stat cache could be harmful?
If no, why make it an option?
If yes, should we
Am 05.09.2021 um 13:30 schrieb Kevin Lyda :
> Any more thoughts on https://github.com/php/php-src/pull/5894 ?
> I've resolved the merge conflict. It would be nice to close out this bug.
For the record in case it was missed:
If we deem the stat cache to be useless I'd rather remove it completely to
Am 03.09.2021 um 18:12 schrieb Kevin Lyda mailto:ke...@lyda.ie>>:
> To run this php script:
>
> $iterations = 100;
> function all_the_stats($filename) {
> @lstat($filename);
> @stat($filename);
> }
> while ($iterations--) {
> all_the_stats(__FILE__);
> }
>
> I see this output:
>
> Wit
Am 03.09.2021 um 17:23 schrieb Nikita Popov :
> Just to throw it out there: Maybe we should clear the stat cache when
> functions in the exec family are used? Even if we allow disabling the stat
> cache, I think we can easily avoid that particular footgun. And if calls to
> external binaries are
Am 03.09.2021 um 16:07 schrieb Kevin Lyda :
> On Fri, Sep 3, 2021 at 2:34 PM Christian Schneider
> wrote:
>> If I remember correctly it was about reducing the number of system calls. Is
>> this no issue any more?
>> Has a quick benchmark been done to see the positive
Am 02.09.2021 um 13:15 schrieb Kevin Lyda :
> Removing it completely would be ideal, however a number of people objected
> in the linked bug. And while it's not needed in modern Unix operating
> systems, it's not clear if Windows might benefit from this.
If I remember correctly it was about reduc
Am 21.06.2021 um 18:54 schrieb tyson andre :
> return [success: true, data: $data, cursor: $cursor];
> // is equivalent to the following, but shorter:
> return ['success' => true, 'data' => $data, 'cursor' => $cursor];
Just a little side-note: A while ago I proposed a 2-line-patch to allow :$foo
1 - 100 of 642 matches
Mail list logo
