|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[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); PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Oct 25 22:00:01 2025 UTC |
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).