Void as return type

问题:

I was testing return types with PHP 7.

I've created a simple script to test return types of PHP 7:

<?php

Class Obj {

    public function __construct(){

    }

    public function test(): string { //a string needs to be returned
        return "ok";
    }

}

function foo(): Obj { //instance of Obj needs to be returned
    return new Obj();
}

$o = foo();
echo $o->test(); // output: ok

Now in other programming languages when you specify a return type void it means you cannot return anything or you will get an error. So I wrote this script:

<?php

    function foo(): void {

    }

    foo(); 

Now in above script the expected output is nothing. Instead it gives me a Fatal error:

Fatal error: Return value of foo() must be an instance of void, none returned on line 2

My question is (I couldn't find it), in PHP 7 will there be a similar void type?

回答1:

Edit:

A new separate RFC for a void return type has been published, has passed the vote, and was implemented in PHP 7.1.
There is now a void return type in PHP. :)

Original Post:

Taken from wiki.php.net:

Future Work

Ideas for future work which are out of the scope of this RFC include:

• Allow functions to declare that they do not return anything at all (void in Java and C)

So currently there is no way to declare that you don't return anything.
I don't know what's best in your situation, but I'd probably just go with not declaring the return type for now.

To answer your question whether there will be a void return type in PHP 7:
There is no guarantee yet, but I think it is very likely that void or a synonym will be implemented in some way.

回答2:

Author of the return types RFC here. In PHP 7.0 there will not be void return types since the RFC didn't add it and neither did any other RFC targeting PHP 7.0.

The type void can exist in the PHP 7 series if we decide that adding new key/reserved words is okay for minor releases even though they will break code. This is somewhat uncertain, but it was done in PHP 5.4 with the callable keyword.

---

Personally, I don't think we need void; we already have null. From the manual:

The special NULL value represents a variable with no value. NULL is the only possible value of type null.

In PHP a function which doesn't return anything will implicitly return null. This means that you cannot ever actually return nothing*. Going the null route means that there are no backwards compatibility breaks since null will not be a valid class/interface/trait name starting in PHP 7.0 and doesn't add any new key or reserved words.

_{*People familiar with the Zend Engine will realize that you can return nothing, but if you returned nothing the variable you are assigning will be assigned null, which makes them logically equivalent.}

---

In PHP 7.1 there will be a void pseudo-type. It is defined in the Void Return Type RFC.

Personally I'm sad about this because the RFC author had previously "quit" and I had picked up the RFC. Then next thing I know it's proposed and in discussion and she wouldn't wait for me to propose union types, which would have been the counterpart to void as noted above. Oh well.

回答3:

The voidreturn type was accepted for php 7.1. So it will come in the future.

Some examples on how it will work:

function should_return_nothing(): void {
    return 1; // Fatal error: A void function must not return a value
}

function returns_null(): void {
    return null; // Fatal error: A void function must not return a value
}
function lacks_return(): void {
    // valid
}
function returns_nothing(): void {
    return; // valid
}

See the RFC from Andrea Faulds for more info!

回答4:

There is no equivalent type for void in php, return NULL; may fits your requirement since it doesn't have any type like 0 or any other value. Note: actual void means no return.

回答5:

@BeNice I understand your point, anyhow I summarize the consideration from Levi Morrison as a practical question of sustainability: introducing void as a possible return type infact, we break the assumption that the only possible type of null is null.

This way, void should be returned for the type check of null, changing architecture constraints by design and causing a mess in backward compatibility.

// your choice implies this comparison should be true:
gettype(null) === void;

I think who used null not frequently in his code would bear the void type implementation.