ChatGPT解决这个技术问题 Extra ChatGPT

Nullable return types in PHP7

PHP 7 introduces return type declarations. Which means I can now indicate the return value is a certain class, interface, array, callable or one of the newly hintable scalar types, as is possible for function parameters.

function returnHello(): string {
    return 'hello';
}

Often it happens that a value is not always present, and that you might return either something of some type, or null. While you can make parameters nullable by setting their default to null (DateTime $time = null), there does not appear to be a way to do this for return types. Is that indeed the case, or am I somehow not finding how to do it? These do not work:

function returnHello(): string? {
    return 'hello';
}

function returnHello(): string|null {
    return 'hello';
}
PHP7 won't allow nullable return types yet, but there's an RFC that aims to address this in PHP 7.1 here. The propesed notation would then be function returnString(?string $stringNull) : ?string { return $stringNull;}
I've ended up emulating nullability by abusing exceptions in my application for now. If you're fine with being silly as well, this might be of use: github.com/JeroenDeDauw/OhMyPhp/blob/master/src/…
Perhaps it might make more sense to use the PHP7 Trowable interface (specifically, extending the TypeError)

C
Community

PHP 7.1 Now supports nullable return types. The first RFC I linked to is the one they went for:

function nullOrString(int $foo) : ?string
{
    return $foo%2 ? "odd" : null;
}

old answer:

Since my comment was actually an answer to the question:

PHP 7 won't support nullable return-types just yet, but there's an RFC out to address just that, it aims to land in PHP 7.1. If it passes, the syntax would then affect all type-hints (both return types and type-hints):

public function returnStringOrNull(?array $optionalArray) : ?string
{
    if ($optionalArray) {
        return implode(', ', $optionalArray);//string returned here
    }
    return null;
}

There's also a competing RFC to add union types, which would be able to do the same thing, but would look different:

public function returnStringOrNull(array|null $optionalArray) : string|null
{
    if ($optionalArray) {
        return implode(', ', $optionalArray);//string returned here
    }
    return null;
}

For now, though, you'll have to write:

public function returnStringOrNull( array $optionalArray = null)
{
    if ($optionalArray) {
        return implode(', ', $optionalArray);
    }
}

Or just return an empty string to be consistent with the return type, and check falsy value:

public function returnStringOrNull( array $optionalArray = null) : string
{
    if ($optionalArray) {
        return implode(', ', $optionalArray);
    }
    return '';
}
//call
$string = $x->returnStringOrNull();
if (!$string) {
    $string = $x->returnStringOrNull(range(1, 10));
}

PHP 7 won't support nullable return-types just yet, but there's an RFC out to address just that - yeah, RFC, "just yet". Do not get me wrong - I'm really heavy PHP user since really crappy PHP3 times till now, no gaps, but when I saw all these RFCs they rejected for 7, my impression was just "WTF?!". Users see the mess and are willing to clean it up in the backward compatible way and they just get "no". Clean methods naming mess? Fixed null not being too special citizen? No, not needed. Add option to make all stuff case sensitive? Nah.. And then, surprise that people switch.
@MarcinOrlowski: A nullable return type-hint would make sense. I've followed a couple of the RFC's for 7, and I agreed for the most part with them rejecting a lot of them. The changes they were focussing on weren't so much on the language as they were on the runtime and compiler. For some of the RFC's that were declined, it's worth reading through the discussion threads to understand why they chose not to implement those changes (eg deprecating var). What is a pitty is that instead, they did accept one too many nice-to-have's (spaceship operator for example)
@EliasVanOotegem Nullable types are now properly supported, as 7.1 was released on 1 December.
@lonesomeday: Indeed it does, added the link + basic example to the bottom of my answer
mmm ish a good type to update this answer! i.e. the union type does not appear to be supported in PHP 7.1
t
the_nuts

Nullable Types are available in PHP 7.1.

This is a syntax example:

public function getName(): ?string
{
    return $this->name; // name can be null
}

PHP 7.1 is now GA and you can upgrade from PHP 7.0 (there are only few backward incompatible changes that you have to check)


IMO it is a joke to deliver return type declarations without implementing "nullable". Return types are unusable until "nullable" feature is implemented.
@joonas.fi IMO strictly typed return values should always be of that type, a null return doesn't hold to that contract and should rather throw an exception giving more meaning to the reason of a null value.
@SteveBuzonas if you consider a method getAgeInYears() on an object representing a Person, how would you model a person that haven't told us his/her age? Return null? Return 0? Returning null semantically means "we don't know", while 0 semantically means "the person is 0 years old". Therefore I'd argue getAgeInYears(): ?int to be the best design. Throwing exceptions should be reserved for well... exceptional cases. Not knowing a person's age in most systems should not be considered an exceptional case.
@joonas.fi very true, and that is a common practice. However, your implementation now needs to be aware that the field is nullable and explicitly handle accordingly. Which very well may be do x except when null which could just as easily be implemented with a try/catch. Further, if one were to actually require a value in that nullable field to continue execution, an exception is likely a better option.
I've noticed that this syntax causes PHPMD to throw a lot of errors. Hopefully they fix it soon.
ס
סטנלי גרונן

It works with any type. Example:

public function getOpportunity(): ?Opportunity
{
    return $this->opportunity;
}