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

G.P.B. wrote:

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:

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.

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."

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, 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é