Req #79695 [Com]: Request nullability of mixed in php 8 be reconsidered

Edit report at https://bugs.php.net/bug.php?id=79695&edit=1 ID: 79695 Comment by: markscherer at gmx dot de Reported by: corey dot taylor dot fl at gmail dot com Summary: Request nullability of mixed in php 8 be reconsidered Status: Not a bug Type: Feature/Change Request Package: Compile Failure PHP Version: master-Git-2020-06-12 (snap) Block user comment: N Private report: N New Comment: 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. Previous Comments: ------------------------------------------------------------------------ [2020-06-12 12:24:32] 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 07:18:22] 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 06:45:23] 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 06:43:47] 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:32:00] 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); ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=79695&edit=1