[RFC] [DISCUSSION] Allow void return type for constructors/destructors

From a PHP developer's POV - when writing a class or refactoring one. I
have to catch myself all the time trying to declare ": void" on the
constructor. It's mostly a habit from doing so with the other methods in
the class. I lean in favor of being able to declare a void return type on a
constructor, but only for the aforementioned reason. I have never ran into
a use case where I've questioned what the return type is for a constructor.
Although I could see newcomers to PHP / Development in general ponder that
thought.

Thanks,
Jesse Rushlow

G.P.B. wrote:

Seems like a no brainer and a good addition. :)

For situations where stuff is simple, 'no brainers' are okay.
For situations where everything is horribly convoluted, 'no brainers'
are often bad.

Benas IML wrote:

even though no return type means mixed|void

Not quite.

No return type is treated as 'mixed|void' in some circumstances
particularly signature checks during inheritance. That's not quite the
same as 'meaning' the same.

What I meant, was that since no return type means mixed|void,
you can't do the following:

I'm actually not sure exactly what you're trying to say there, but I
think pasting the text I reference whenever trying to think about LSP
might be useful...

"PHP allows contravariance (aka type widening) for parameter types to
obey the LSP principle. A subclass may use a 'wider' aka less specific
type in place of the inherited type for a parameter."

"PHP allows covariance (aka type narrowing) for return types to obey
the LSP principle. A subclass may use a 'narrower' aka more specific
type in place of the inherited type for a function return."

I am proposing to allow void return type for constructors/destructors.

Constructors in PHP have multiple issues that are 'surprising'. I'm
not sure that fixing only a small part of how they are surprising,
improves PHP drastically.

Also...I really wish we already had null as a usable type, as most of
the uses of void are slightly inaccurate.

The meaning of void and null are:

void - this function doesn't return a value
null - this function returns a value that has no information in it.

Presumably you want to be able to specify void as the return type to
make it be easier to detect errors in code like the example you
provided.

It seems that making a rule for whichever static analyzer you're
using, that errors on any assigning of a value from a __construct
call, would achieve that, without touching a part of PHP that is full
of edge cases.

To be clear, I'm not sure if I am in favour or against the RFC. The
real problem is that constructors just don't fit into how we think
about normal functions is PHP, because of the magic that goes on
around them and so both void and null as return types would be a
little bit incorrect.

cheers
Dan
Ack

Some example functions using those two return types.

function this_is_void_return(): void {
exit(0);
}

function this_is_also_void_return(): void {
throw new Exception("no usuable return value");
}

function this_is_also_also_void_return(): void {
while (1) {
echo "Hello world\n";
}
}

function this_is_null_return(): null {
// deliberately empty.
}

// This code is fine.
var_dump(this_is_null_return());

// This code is never going to execute the var_dump, which
// might indicate an error.
var_dump(this_is_void_return());
var_dump(this_is_also_void_return());
var_dump(this_is_also_also_void_return());

Hey Dan,

Thanks for your reply.

No return type is treated as 'mixed|void' in some circumstances
Could you elaborate? No return type DOES mean mixed|void, could you give
any pointers as to where that is different?

I'm actually not sure exactly what you're trying to say there
I meant something like this:

<?php
class Test {
    public function __construct() {}
}

class Test2 extends Test {
    /* this is legal */
    public function __construct(): void {}
}

class Test3 extends Test {
    /*
     * this is illegal, even though no
     * return type means mixed|void
     */
    public function __construct(): mixed {}
}

class Test4 extends Test2 {
    /*
     * this is legal, even though we are
     * widening void type to mixed|void
     * but LSP checks don't apply to
     * constructors and destructors
     */
    public function __construct() {}
}

This RFC's goal isn't to fix constructor issues. My goal is to allow to
(for those that want to) add an optional void return type to
constructors/destructors (for example to have complete consistency with
other methods).

G.P.B. wrote:

Seems like a no brainer and a good addition. :)

For situations where stuff is simple, 'no brainers' are okay.
For situations where everything is horribly convoluted, 'no brainers'
are often bad.

Benas IML wrote:

even though no return type means mixed|void

Not quite.

No return type is treated as 'mixed|void' in some circumstances
particularly signature checks during inheritance. That's not quite the
same as 'meaning' the same.

What I meant, was that since no return type means mixed|void,
you can't do the following:

I'm actually not sure exactly what you're trying to say there, but I
think pasting the text I reference whenever trying to think about LSP
might be useful...

"PHP allows contravariance (aka type widening) for parameter types to
obey the LSP principle. A subclass may use a 'wider' aka less specific
type in place of the inherited type for a parameter."

"PHP allows covariance (aka type narrowing) for return types to obey
the LSP principle. A subclass may use a 'narrower' aka more specific
type in place of the inherited type for a function return."

I am proposing to allow void return type for constructors/destructors.

Constructors in PHP have multiple issues that are 'surprising'. I'm
not sure that fixing only a small part of how they are surprising,
improves PHP drastically.

Also...I really wish we already had null as a usable type, as most of
the uses of void are slightly inaccurate.

The meaning of void and null are:

void - this function doesn't return a value
null - this function returns a value that has no information in it.

Presumably you want to be able to specify void as the return type to
make it be easier to detect errors in code like the example you
provided.

It seems that making a rule for whichever static analyzer you're
using, that errors on any assigning of a value from a __construct
call, would achieve that, without touching a part of PHP that is full
of edge cases.

To be clear, I'm not sure if I am in favour or against the RFC. The
real problem is that constructors just don't fit into how we think
about normal functions is PHP, because of the magic that goes on
around them and so both void and null as return types would be a
little bit incorrect.

cheers
Dan
Ack

Some example functions using those two return types.

function this_is_void_return(): void {
exit(0);
}

function this_is_also_void_return(): void {
throw new Exception("no usuable return value");
}

function this_is_also_also_void_return(): void {
while (1) {
echo "Hello world\n";
}
}

function this_is_null_return(): null {
// deliberately empty.
}

// This code is fine.
var_dump(this_is_null_return());

// This code is never going to execute the var_dump, which
// might indicate an error.
var_dump(this_is_void_return());
var_dump(this_is_also_void_return());
var_dump(this_is_also_also_void_return());

To be clear, I'm not sure if I am in favour or against the RFC. The
real problem is that constructors just don't fit into how we think
about normal functions is PHP, because of the magic that goes on
around them and so both void and null as return types would be a
little bit incorrect.

I'm not clear what you mean by this. The definition of ": void" is
currently that the function must either use "return;" without a value, or
conclude without an explicit "return"; a correctly written constructor
would meet that constraint.

The language doesn't currently prevent void functions from being used in
expression context, but even if it did, that would be consistent with how
constructors are actually called internally, which is roughly equivalent to
this:

$newInstance = initialise_object($classDefinition);
$newInstance->__construct(...$args);
return $newInstance;

If a constructor returns a value, it is simply discarded, so a signature of
void would be completely appropriate.

Regards,

Rowan Tommins
[IMSoP]

Thanks everybody for the replies.

However, I am also fine if the void return value is only enforced when the void return
type is declared. Additionally, we could emit a deprecation notice/warning when
there is no return type declaration, but a value is returned. I think this would be
a nice way to immediately give people the possibility to disallow a return value,
while being respectful for older code bases.

Completely agreed. I'll update the RFC to reflect this as well.

We should allow newer codebases to enforce void rules on
constructors/destructors
by allowing to explicitly declare return type as void.

Meanwhile, we should throw a deprecation warning, if the
constructor/destructor is
returning a non-void value and doesn't have an explicit : void
declaration. Then,
presumably in PHP 9, in addition to explicit : void, also enforce
void rules implicitly
altogether.

Best regards,
Benas

This PR should also address all of Máté's concerns since it makes
constructors and destructors always return void (even when no explicit
void return type is specified).

To be clear, my main concern was that declaring a void return type shouldn't be
allowed, unless it's actually enforced. Now, it's all fine because you stated your
intentions :)

However, I am also fine if the void return value is only enforced when the void return
type is declared. Additionally, we could emit a deprecation notice/warning when
there is no return type declaration, but a value is returned. I think this would be
a nice way to immediately give people the possibility to disallow a return value,
while being respectful for older code bases.

Regards,
Máté