Hi,
The vote has ended.
The RFC was accepted by 26 vs 0.
Also, 25 vs 0 voted to remove the old JIT implementation right after
merging the new one.
I'm going to merge the Pull Request next week (on Monday or Tuesday) and
then remove the old JIT implementation in the next few days.
Let me know if s
Hi
A while ago I noticed that the current error messages when the
memory_limit is reached / when an OOM condition is encountered are
misleading, because PHP allocates memory from the operating systems in
bulk in larger chunks and the size of the chunk is what is checked
against the memory lim
On Thu, Oct 19, 2023 at 12:14 AM Pierre wrote:
>
> Maybe I don't master english enough and I can speak to strictly
> sometime. If an operator overload RFC that doesn't have any blind spot
> or weird edge case happens, I'd be happy to see it pass, at least it
> would close bike shedding around thi
On Thu, Oct 19, 2023, at 11:26 AM, Ilija Tovilo wrote:
>> 2. Lots of request bodies are not forms these days; they're frequently JSON
>> or GraphQL. This function would be useless in those cases; that's fine, but
>> should the name then suggest that it's for form data only?
>> request_parse_f
2023年10月19日(木) 22:33 Niels Dossche :
>
> Hi Yuya
>
> On 19/10/2023 13:57, youkidearitai wrote:
> > Hi, internals.
> >
> > 8ctopus san can't send email, so I'm writing new RFC for multibyte
> > trim function.
> > https://wiki.php.net/rfc/mb_trim
> > https://github.com/php/php-src/pull/12459
> >
> >
Hi Yuya
On 19/10/2023 13:57, youkidearitai wrote:
> Hi, internals.
>
> 8ctopus san can't send email, so I'm writing new RFC for multibyte
> trim function.
> https://wiki.php.net/rfc/mb_trim
> https://github.com/php/php-src/pull/12459
>
> I would like to under discussion.
Thanks for this.
I hav
Hi, internals.
8ctopus san can't send email, so I'm writing new RFC for multibyte
trim function.
https://wiki.php.net/rfc/mb_trim
https://github.com/php/php-src/pull/12459
I would like to under discussion.
Regards.
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-mem
Hi Larry
On Wed, Oct 18, 2023 at 7:26 PM Larry Garfield wrote:
> > On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo wrote:
> >> https://wiki.php.net/rfc/rfc1867-non-post
>
> The functionality all seems reasonable to me. I have a few smaller concerns:
>
> 1. Like Derick, I think I'd favor including t
On 18 Oct 2023, at 13:50, someniatko wrote:
> There were already suggestions on the mailing list to allow "overloading"
> existing `==` operator, and some suggestions went even as far as overloading
> `<`, `>=` etc operators.
Slightly off-topic, but concatenation?
Just as a possible feature..
Hi,
On 26.09.23 12:39, Marc Bennewitz wrote:
Hi internals
I'd like to put a new RFC under discussion:
https://wiki.php.net/rfc/integer-rounding
Best,
Marc
Based on the discussion I see two groups. The one that would like to
change this behavior without message (bug fix) and others that see a
On 10/18/23 20:20, Lanre Waju wrote:
I believe it's time to shift our focus away from backward compatibility
(BC) concerns in major versions. In my opinion, genuine operator
overloading is incomparable to the pseudo operator. I genuinely see the
operator overloads as an invaluable addition to P
Hi Jakub,
On 16.10.23 00:17, Jakub Zelenka wrote:
Your JSON example is a bit unrelated because if you care about your
types your should have used JSON_RESERVE_ZERO_FRACTION in the first
place else you should not care about int vs float at all.
The thing is that JSON might be encoded by anothe
Le 18/10/2023 à 22:22, Jordan LeDoux a écrit :
While I (obviously) appreciate the goal of the proposal here since I
wrote the gigantic operator overload RFC the last time it was
proposed, I do not support this idea here for one very simple reason:
it is a clunky, work-around implementation to
13 matches
Mail list logo
