On 3 June 2025 03:38:58 BST, Larry Garfield wrote:
>I fundamentally do not believe pulling arbitrary files into such a structure
>is wise, possible, or will achieve anything resembling the desired result,
>because *basically no application or library is single-file anymore*.
I don't think a
On Mon, Jun 2, 2025, at 3:41 PM, Dmitry Derepko wrote:
> Hi Larry!
>
>
>
> It's been a long, long way to get this feature, awesome work.
>
>
>
> Have you considered adding a compose function that does the same thing
> but in the classic PHP function style?
>
>
>
> There's not much difference betwe
Hey Larry,
Thanks for your answer.
> On 2. Jun 2025, at 21:39, Larry Garfield wrote:
> This was discussed heavily in the design and discussion phase for hooks. The
> main problem is that the expectations for readonly and the expectations for
> hooks don't always align. For example, if a virt
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 null values.
With the introduction of named arguments and promoted
On 02/06/2025 20:01, Larry Garfield wrote:
The result of this RFC is that the following would no longer be an error, yes?
function test(): void {
print "test";
}
// This currently gives an error, but you propose that it
// would change to set $val to null?
$val = test();
There is no error:
On 02/06/2025 23:50, Rowan Tommins [IMSoP] wrote:
I agree the type hierarchy you describe is weird, but rather than
throwing away the functionality completely, I wonder if we can make it
more consistent:
- Make "no return type declared" and "mixed" equivalent
- Make "void" a sub-type of "null"
Hi Gina
On Mon, Jun 2, 2025 at 6:28 PM Gina P. Banyard wrote:
>
> RFC: https://wiki.php.net/rfc/void-as-null
After a read, I think I fundamentally disagree with the proposal. It
says (regarding the status-quo):
> * void is not a subtype of a function with a mixed return type
This is laid out a
On Mon, Jun 2, 2025, at 3:20 AM, 马正强 wrote:
> Hi Rowan,
>
> Thank you for the clear technical guidance. I agree we've reached a
> consensus that implementing a native Map type would be the proper
> solution to this long-standing issue.
>
> To move forward, I'd like to clarify a few practical
On Mon, Jun 2, 2025, at 18: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 wiki, so there
> might be a few oddities.
>
> The RFC propos
On 02/06/2025 17:27, Gina P. Banyard wrote:
The objective is to fix a weird quirk of PHP's type system, where void lives in
its own type hierarchy.
This is visible mainly in that a lack of return type is not isomorphic to a
function that has a return type of mixed.
I think if "void" was adde
Hi everyone,
As there was no additional feedback for the last 5 days, and we feel the
RFC is in a good place, we intend to start voting on Wednesday if there are
no new concerns raised.
Thank you again!
Volker
On Mon, May 26, 2025 at 4:03 PM Volker Dusch
wrote:
> Version 1.1 Update: Array synt
Hi Larry!
It's been a long, long way to get this feature, awesome work.
Have you considered adding a compose function that does the same thing but
in the classic PHP function style?
There's not much difference between the new style:
$processor = fn ($data) => htmlentities($data)
|> st
On 02/06/2025 17:57, Larry Garfield wrote:
Well, now you're talking about something with a totally separate compile step,
which is not what Michael seemed to be describing at all. But it seems like
that would be necessary.
There's definitely some crossed wires somewhere. I deliberately left
On Mon, Jun 2, 2025, at 7:49 AM, Nick wrote:
> Dear Internals,
>
> I am sending my first message here. Thank you all for your hard work!
Greetings.
> I believe promoted properties should allowed for `readonly` properties
> and in `readonly` classes. This would help us to avoid the unnecessary
>
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 wiki, so there might
be a few oddities.
The RFC proposes to deprecate implicit type coercions to and from the bool type
for o
On Mon, Jun 2, 2025, at 11:27 AM, Gina P. Banyard wrote:
> Hello internals,
>
> This is the second RFC out of a set of type system related RFCs I want
> to propose for PHP 8.5.
>
> The objective is to fix a weird quirk of PHP's type system, where void
> lives in its own type hierarchy.
> This is
The RFC mentions that this will now become valid:
function foo(): void {
return null;
}
But what about the opposite:
function foo(): null {
return;
}
or what Larry was trying to suggest:
function foo(): null {
print 'test';
}
$val = foo();
On Mon, Jun 2, 2025, at 9:44 AM, Rowan Tommins [IMSoP] wrote:
> On 2 June 2025 14:27:45 BST, Larry Garfield wrote:
>>Were we to do that, then the consumer container-loading needs to take any
>>potential module-definition into account. Eg, if one class from a module is
>>pulled into a container,
Hello internals,
This is the second RFC out of a set of type system related RFCs I want to
propose for PHP 8.5.
The objective is to fix a weird quirk of PHP's type system, where void lives in
its own type hierarchy.
This is visible mainly in that a lack of return type is not isomorphic to a
fu
On 2 June 2025 14:27:45 BST, Larry Garfield wrote:
>Were we to do that, then the consumer container-loading needs to take any
>potential module-definition into account. Eg, if one class from a module is
>pulled into a container, all of them must be.
You wouldn't containerize "something from
On Sun, Jun 1, 2025, at 5:01 PM, Rowan Tommins [IMSoP] wrote:
> On 01/06/2025 17:05, Larry Garfield wrote:
>> I think there's a key assumption here still that is at the root of much of
>> the disagreement in this thread.
>>
>> Given that code from multiple files is clustered together into a "thing
Dear Internals,
I am sending my first message here. Thank you all for your hard work!
PHP has evolved amazingly over the past few years; I love it.
Promoted properties allow us to write very neat value objects, with almost no
boilerplate.
Now, with property hooks, we can eliminate even more bo
Hi Rowan,
Thank you for the clear technical guidance. I agree we've reached a
consensus that implementing a native Map type would be the proper solution
to this long-standing issue.
To move forward, I'd like to clarify a few practical aspects:
1. **RFC Proposal**
- Should I initiate an RFC dr
23 matches
Mail list logo
