On 5.6.2025 02:59:56, Daniel Scherzer wrote:
On Wed, Jun 4, 2025 at 4:49 PM Bob Weinand wrote:
Hey Daniel,
where's the BC break? Nothing which worked today will stop working
(except you won't get exceptions in some cases). That's not a BC
break. The only thing which stops worki
On Mon, Jun 2, 2025, at 18:27, 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
On Wed, Jun 4, 2025 at 4:49 PM Bob Weinand wrote:
> On 4.6.2025 22:39:28, Daniel Scherzer wrote:
>
> On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand wrote:
>
>>
>> On 4.6.2025 16:54:05, Bob Weinand wrote:
>> > On 2.6.2025 18:27:51, Gina P. Banyard wrote:
>> >> Hello internals,
>> >>
>> >> This is the
On 4.6.2025 22:39:28, Daniel Scherzer wrote:
On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand wrote:
On 4.6.2025 16:54:05, Bob Weinand wrote:
> On 2.6.2025 18:27:51, Gina P. Banyard wrote:
>> Hello internals,
>>
>> This is the second RFC out of a set of type system related RFCs I
On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand wrote:
>
> On 4.6.2025 16:54:05, Bob Weinand wrote:
> > On 2.6.2025 18:27:51, 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 objecti
On 2.6.2025 18:27:51, 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 visible mainly in that a
On 4.6.2025 16:54:05, Bob Weinand wrote:
On 2.6.2025 18:27:51, 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 typ
On Wednesday, 4 June 2025 at 09:50, Tim Düsterhus wrote:
> Am 2025-06-03 17:42, schrieb Gina P. Banyard:
>
> > A type system should be logical, and the fact that the top type (mixed)
> > is not a super-type of all types doesn't make any sense.
>
>
> I do not consider `void` to be a type per se
Hi
Am 2025-06-03 17:46, schrieb Gina P. Banyard:
> IMO, these checks are useful enough not to be removed.
I agree with Ilija (and also Rowan).
Well, I'm not sure Ilija and Rowan agree between each other.
I believe they agree in that the distinction between `void` and `null`
is a useful one
Hi
Am 2025-06-03 17:42, schrieb Gina P. Banyard:
A type system should be logical, and the fact that the top type (mixed)
is not a super-type of all types doesn't make any sense.
I do not consider `void` to be a type per se, but rather as an indicator
for the absence of a value. Basically the
On Tue, Jun 3, 2025, at 4:33 AM, Christoph M. Becker wrote:
> On 03.06.2025 at 03:36, Anton Smirnov wrote:
>
>> 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";
>
On 03/06/2025 18:20, Gina P. Banyard wrote:
On Tuesday, 3 June 2025 at 02:36, Anton Smirnov wrote:
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 c
On Tuesday, 3 June 2025 at 16:18, Tim Düsterhus wrote:
> Am 2025-06-03 01:46, schrieb Ilija Tovilo:
>
> > IMO, these checks are useful enough not to be removed.
>
> I agree with Ilija (and also Rowan).
Well, I'm not sure Ilija and Rowan agree between each other.
AFAIU Ilija thinks void living o
On Tuesday, 3 June 2025 at 02:36, Anton Smirnov wrote:
> 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 r
Hi
Am 2025-06-03 01:46, schrieb Ilija Tovilo:
IMO, these checks are useful enough not to be removed.
I agree with Ilija (and also Rowan). To me there is an important
semantic difference between “not returning anything” and “always
returning null”. I believe that `void` being in a distinct ty
On Monday, 2 June 2025 at 21:53, Rowan Tommins [IMSoP]
wrote:
> 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 t
On Monday, 2 June 2025 at 18:08, Kamil Tekiela wrote:
> The RFC mentions that this will now become valid:
>
> function foo(): void {
> return null;
> }
>
> But what about the opposite:
>
> function foo(): null {
> return;
> }
This would also work indeed.
> or what Larry was trying to suggest
On 03.06.2025 at 03:36, Anton Smirnov wrote:
> 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
>>
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 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
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();
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
25 matches
Mail list logo
