Maybe a
#[\SuppressUndefinedWarning]
Parameter attribute could work, then everyone could implement their own
blank() function with their own preferred logic
Not sure if it's technically feasible tho, now the php engine would need to
inspect the parameter attributes before deciding on generating a
Oops, I made a mistake in the logic of `Scope` and coroutines.
According to the RFC, the following code behaves differently:
```php
currentScope()->spawn ... // This coroutine belongs to the Scope
spawn ... // This one is a child coroutine
```
I was sure that I had checked all the major edge cas
Am 20.03.2025 um 15:51 schrieb Rob Landers :
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
Okay, I see the point with LSP. I'm not sure whether we need to preserve LSP
for that specific scena
On 2025-03-20 18:50, Daniel Scherzer wrote:
The original inspiration which I discussed in the RFC is fixing the
signature of the BackedEnum methods, which currently use the second
option.
Hey,
I'm not opposed to having a bottom type, but the `try`/`tryFrom` issue
feels caused by another
On Thu, Mar 27, 2025, at 9:30 AM, Ilija Tovilo wrote:
> Hi Larry
>
> Sorry for the late response.
>
> On Fri, Feb 7, 2025 at 5:58 AM Larry Garfield wrote:
>>
>> https://wiki.php.net/rfc/pipe-operator-v3
>
> We have already discussed this topic extensively off-list, so let me
> bring the list up-to
On Fri, Feb 21, 2025 at 12:09 PM Daniel Scherzer <
daniel.e.scher...@gmail.com> wrote:
> Hi internals,
>
> I recently found out that constructor property promotion cannot be used
> for final properties. I propose that it become allowed. Thoughts? Would
> this need an RFC, or is this minor enough t
Hi
I looked at it earlier, when you opened the PR.
I also remember the discussion from the past.
Your PR is super logical, and a super easy implementation.
Language change seems unnecessary indeed.
LGTM, ship it!
Kind regards
Niels
On Saturday, 15 March 2025 at 09:23, Juris Evertovskis wrote:
> On 2025-03-14 10:09, Juris Evertovskis wrote:
>
>> Hello,
>>
>> I’ve opened the vote on the Optional interfaces RFC.
>>
>> https://wiki.php.net/rfc/optional-interfaces
>>
>> Implementation: https://github.com/php/php-src/pull/17288
>
>
> "Cheating" in the sense that you wrote out a "general syntax",
>
I got it.
> That's not the problem; the problem is that the following are all
equivalent expressions:
> (((foo(
In principle, this is not a problem because the expression in parentheses
preceded by `spawn` is unambiguously
On Wed, Apr 2, 2025, at 07:54, Viktor Khramov wrote:
> Hi Rob.
> The examples in this RFC only describe usage within classes as far as I can
> see.
> Does this finally solve the factory methods issue?
> https://externals.io/message/126452
>
> пн, 31 мар. 2025 г. в 23:38, Rob Landers :
>> __
>> O
Continuing the discussion from [[PHP-DEV] PHP True Async RFC - Stage 2](
https://discourse.thephp.foundation/t/php-dev-php-true-async-rfc-stage-2/1573/16
):
[quote="Crell, post:16, topic:1573"]
// Creates an async scope, in which you can create coroutines.
[/quote]
Yes, I understand what this is
Hi
Am 2025-03-20 17:09, schrieb Gina P. Banyard:
And another user [2] was basically suggesting my previous solution of
adding support for type classes/runtime implementation of interfaces.
[…]
[2] https://www.reddit.com/r/PHP/comments/1jbcbtx/comment/mhvxo5j/
I don't see how this could (usefu
On Thu, Mar 20, 2025, 18:58 Rob Landers wrote:
>
>
> On Thu, Mar 20, 2025, at 16:41, Bob Weinand wrote:
>
>
> Am 20.03.2025 um 16:28 schrieb Rob Landers :
>
>
>
>
> On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
>
>
> Am 20.03.2025 um 15:51 schrieb Rob Landers :
>
>
>
>
> On Wed, Mar 19,
On Sun, 23 Mar 2025 at 12:52, Robert Chapin wrote:
>
> Hi PHP folks,
>
> I submitted a proposal on Monday that received no replies. The idea was
> about adding a functional construct nullc() that could act as an inline
> null coalesce for a variable. That task is currently not possible in a
> nu
Am 20.03.2025 um 16:28 schrieb Rob Landers :
On Thu, Mar 20, 2025, at 16:12, Bob Weinand wrote:
Am 20.03.2025 um 15:51 schrieb Rob Landers :
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
On 19.3.2025 16:04:06, Rob Landers wrote:
On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
Hi Kayck,
Thanks for your proposal. Here are some points from me:
empty() is not a function, it's a language construct that's a shorthand for
!isset($var) || $var == false.
While it has its uses empty() should be avoided whenever possible. It's
generally a sign of the programmer being lazy not d
On Thu, Mar 20, 2025, at 11:24 AM, Gina P. Banyard wrote:
> As the person that had the initial discussion in R11 with Jordan [1]
> never as a parameter type for an interface actually is not the solution
> for "poor man generics".
> Matthew Fonda [2] already replied to the thread pointing out the
On Thu, Mar 13, 2025 at 4:00 PM Calvin Buckley wrote:
> It's time to start the process of finding and electing RMs for the next
minor PHP release.
Hi Internals,
I’m Volker Dusch, @edorian in most places.
PHP has been a big part of my life for the last 20 years. From helping with
maintaining PH
On Tue, Apr 1, 2025 at 12:40 PM Tim Düsterhus wrote:
>
> If you are at the point where you need mutually recursive closures,
> perhaps you should just use named functions / an anonymous class. I
> don't find it useful to “optimize DX” for that case, since
> self-recursive Closures are already some
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
*INTRODUCTION*
This RFC proposes the addition of a new global function blank() to PHP’s
core, intended to provide a more intuitive and context-sensitive way of
checking for "blank" values. This function is *not a replacement* for
empty(), but a *complementary tool *to help developers more accuratel
Hello,
I'm now deep into the rabbit hole of trying out "\" as the separator. It does
give some nice ergonomics when using the nested/inner classes, and I really
like it much better than ":>", but the amount of technical debt I have run into
is enormous. For now, my implementation will probably
Hi
Am 2025-03-31 22:38, schrieb Ilija Tovilo:
Do you have thoughts or concerns with this solution? If not, I'm
planning to merge it into master in a few weeks.
I don't particularly like this kind of “magic scope / backtrace
introspecting” functions, but it certainly is a pragmatic solution (a
On 03/04/2025 08:22, Larry Garfield wrote:
However, it also received significant pushback off-list from folks who felt it
was too much magic. I don't want to torpedo pipes on over-reaching. But
without feedback from other voters, I don't know if this is over-reaching. Is
it? Please, someon
On 01.04.2025 at 08:59, Andrew Lyons wrote:
> I've been a PHP developer since the early days and have contributed to
> docs. I've also represented my employer (Moodle) on the PHP Foundation.
>
> I'd like edit access to the wiki so that I can possibly submit an RFC (if
> required) to change the def
On 1 April 2025 20:52:32 BST, Larry Garfield wrote:
>On Mon, Mar 31, 2025, at 5:03 PM, Niels Dossche wrote:
>> 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.
>>
>> Hear me out.
>> We
On 05/04/2025 15:32, Kamil Tekiela wrote:
While it has its uses empty() should be avoided whenever possible.
Agree. A better RFC would be to just deprecate `empty()`.
Cheers,
Bilge
On 05/04/2025 20:18, Rob Landers wrote:
On Sat, Apr 5, 2025, at 21:10, Bilge wrote:
On 05/04/2025 19:41, Rob Landers wrote:
empty() has very many uses.
That is exactly the same as saying `==` has many uses. It does. So
many uses that it's useless. Its semantics are nonsense.
if (isset($var)
On Sat, Apr 5, 2025, at 21:23, Bilge wrote:
> On 05/04/2025 20:18, Rob Landers wrote:
>> On Sat, Apr 5, 2025, at 21:10, Bilge wrote:
>>> On 05/04/2025 19:41, Rob Landers wrote:
empty() has very many uses.
>>> That is exactly the same as saying `==` has many uses. It does. So many
>>> uses t
On Sat, Apr 5, 2025, at 21:10, Bilge wrote:
> On 05/04/2025 19:41, Rob Landers wrote:
>> empty() has very many uses.
> That is exactly the same as saying `==` has many uses. It does. So many uses
> that it's useless. Its semantics are nonsense.
>>
>> if (isset($var) && $varl != false) {
>> foo(
On Sat, Apr 5, 2025, at 14:15, Kayck Matias wrote:
> *INTRODUCTION*
> This RFC proposes the addition of a new global function `blank()` to PHP’s
> core, intended to provide a more intuitive and context-sensitive way of
> checking for "blank" values. This function is *not a replacement* for
> `em
On Sat, Apr 5, 2025 at 11:04 PM Rob Landers wrote:
> On Sat, Apr 5, 2025, at 14:15, Kayck Matias wrote:
>
> *INTRODUCTION*
> This RFC proposes the addition of a new global function blank() to PHP’s
> core, intended to provide a more intuitive and context-sensitive way of
> checking for "blank" va
On Wed, Mar 19, 2025, at 21:09, Bob Weinand wrote:
>
>
> On 19.3.2025 16:04:06, Rob Landers wrote:
>> On Tue, Mar 18, 2025, at 03:37, Bob Weinand wrote:
>>> Okay, I see the point with LSP. I'm not sure whether we need to preserve
>>> LSP for that specific scenario, but neither can I say that w
On Thu, Mar 20, 2025 at 4:00 PM Larry Garfield
wrote:
> I have a use case for this in Serde, so would be in favor.
>
> We should not block this kind of improvement on the hope of generics.
> Worst case, we have this plus generics so you have options, how terrible.
>
>
Would you mind sharing detai
> 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
On 05/04/2025 20:00, Claude Pache wrote:
> Hi Niels,
>
> It is reasonable. I have a userland implementation of that in my codebase
> since long ago.
>
> You missed the following point when discussing the behaviour for empty array:
>
> * Consistent with `array_shift()` and `array_pop()`, which a
Hi Daniel
On Mar 21 2025, at 11:17 pm, Daniel Scherzer
wrote:
> Contributing to php-src with features and bug fixes,
> https://github.com/DanielEScherzer
>
Your account has been approved. You should have received an e-mail with a
GitHub invitation. Derick also granted you the corresponding ka
> echo blank(" "); // true
This case is not blank `empty` checks if a variable is set and contains
something so basically what your blank function does. In this example it
contains character 32. If you want to remove the "\0" (null terminator)
from the language, that's a different story.
On Sat,
On 05/04/2025 19:41, Rob Landers wrote:
empty() has very many uses.
That is exactly the same as saying `==` has many uses. It does. So many
uses that it's useless. Its semantics are nonsense.
if (isset($var) && $varl != false) {
foo($bool);
}
>$varl != false
You should never be doing this
On Sat, Apr 5, 2025, at 20:25, Bilge wrote:
> On 05/04/2025 15:32, Kamil Tekiela wrote:
> >
> > While it has its uses empty() should be avoided whenever possible.
> >
> Agree. A better RFC would be to just deprecate `empty()`.
>
> Cheers,
> Bilge
>
empty() has very many uses. Once you understand
40 matches
Mail list logo
