php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #79695 Request nullability of mixed in php 8 be reconsidered
Submitted: 2020-06-12 06:32 UTC Modified: 2020-06-12 06:45 UTC
From: corey dot taylor dot fl at gmail dot com Assigned:
Status: Not a bug Package: Compile Failure
PHP Version: master-Git-2020-06-12 (snap) OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: corey dot taylor dot fl at gmail dot com
New email:
PHP Version: OS:

 

 [2020-06-12 06:32 UTC] corey dot taylor dot fl at gmail dot com
Description:
------------
We hope we can submit this for consideration as the RFC has just been voted on and implemented.

According to the Nullability clause of (https://wiki.php.net/rfc/mixed_type_v2#nullability), `?mixed` will not be a valid type as `mixed` will already include the type `null`.

You currently get this failure in master branch:

PHP Fatal error:  Type mixed cannot be marked as nullable since mixed already includes null in /home/travis/build/cakephp/cakephp/src/basics.php on line 22

The clause says that a future RFC can allow the redundant types. However, we think this makes code more difficult to write and harder to correct later.

The other clauses state that untyped parameters will be evaluated as `mixed`. Of course, untyped parameters should include `null`. However, we think this can be changed similar to the wording in how untyped returns are evaluated (mixed|void) to `?mixed` or `mixed|null`.

Usually, then a type is `mixed`, it's because it supports many flavors of input. Often these other inputs are documented via @param or @psalm-param docblock entries. In most cases, we explicitly document whether this includes a null value:

@param null|\Closure|\Project\Class

If `null` is automatically defined by `mixed`, then we lose the ability to document that we expect a value to be set. Static analyzers will complain that we don't include `null` when the type is `mixed`.

Static analyzers will have to create their own version of `mixed` for untyped parameters support this kind of documentation. In most cases, we will end up simply not type hinting to avoid the official mixed type.

Further, to the point of this need being discoverable and changed later, it seems that requiring every `mixed` parameter and return type to be changed to `?mixed` to support even further static analyzer changes will be very tedious. How will they be able to easily support this transition?

Our request is that `mixed` not include null and untyped parameters be treated as `?mixed`. But, if nothing else, we would request supporting redundant types `?mixed` to help with type documentation and analysis.

Test script:
---------------
function test_null(?mixed $param): void
{
    var_dump($param);
}

test_null(null);


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-06-12 06:43 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2020-06-12 06:43 UTC] requinix@php.net
This bug tracker is not the appropriate place to raise the issue. Hop on the internals mailing list.
https://www.php.net/mailing-lists.php
 [2020-06-12 06:45 UTC] requinix@php.net
Oh. And please make sure to familiarize yourself with the existing discussions first. I don't remember the details but whether mixed included null *was* discussed.
 [2020-06-12 07:18 UTC] beberlei@php.net
PHP 8 also has a new union types feature that eleviates your concern, you can write:

function foo (null|\Closure|\Project\Class $value) {
}

In the case where you know which different types are part of a "mixed argument type" (so to speak).
 [2020-06-12 12:24 UTC] danack@php.net
"Static analyzers will complain that we don't include `null` when the type is `mixed`."

Please report that as a bug for whichever static analyzer you are using.

If it doesn't understand that mixed includes null, then it doesn't understand the PHP type system.
 [2020-06-12 13:22 UTC] markscherer at gmx dot de
I would like to rephrase this a bit, also as I have mentioned on the PR itself ( https://github.com/php/php-src/pull/5313#issuecomment-636360553 ) .

All other return types added in PHP7+ are either true not-nullable or they are using `?` character.
The mixed now introduces a flaw it that consistency.

You argue from the perspective that the "mixed" docblock type so far meant "mixed|null", which could be true for some. But many actually already used "mixed" for not-nullable and "mixed|null" for nullable on mixed, making sure this is clear when the using code requires isset() or !== null checks.
So yeah, tooling will have to be adjusted either way on this.

but NOW is the time to fix the consistency issue here in terms of return type.

- mixed must not include null
- ?mixed means nullable and should be used as default typehint wherever you are are not sure if something can return null as well

It is and should be as simple as that - and would also be consistent with all other union types added. I also linked that in the PR above: https://wiki.php.net/rfc/union_types_v2

Please re-address or at least discuss this internally to make sure we do not introduce an inconsistency in PHP that could have easily been avoided.
Once PHP8 is out, this can not be that easily rectified anymore.
Thus the importance to clarify this now.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 27 13:01:30 2024 UTC