[RFC] Mixed type

On Mon, Apr 20, 2020 at 5:17 PM Larry Garfield larry@garfieldtech.com
wrote:

On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield larry@garfieldtech.com
wrote:

Here is an RFC for adding a 'mixed' type to the language:
https://wiki.php.net/rfc/mixed_type_v2

I am not against this, but now that we have Union types what places are
there where the currently available type declarations are insufficient?
Resource seems like the only remaining gap where you'd be forced to use
mixed instead of a union.

I imagine some type combinations get pretty wide. Like, this is
verbose AF.

null|bool|int|float|string|array|object|resource

Sure, but how often is that an actual description of what the code
accepts? I... cannot actually envision what code would actually accept
that mess. :-)

I can think of quite a few:

• var_dump, print_r, more generally debugging/logging functions and
  wrappers thereof
• json_encode, serialize, and more generally serialization and encoding
  functions, as return value as well for the inverse operations
• database/nosql related functions (bindParam, bindValue) and as return
  value from generic functions like fetch()
• Xpath::evaluate
• ldap query functions

And wrappers of these extensions could benefit from passing on the mixed
type explicitly.

With union types and stringable already on the way, I'm not sure what
other non-hypothetical use cases would still be that fugly that you'd now
need to fall back to mixed. (I still think intersection types are
needed, but that's a separate matter.) There may be, but I cannot think of
them.

For the long term good of the language I'd prefer type aliases (or
typedefs
or usings or whatever you want to call them.

use mixed = null|bool|int|float|string|array|object|resource;
use scalar = null|bool|int|float|string;
use number = int|float;

Concur.

That said, baking 'mixed' in as an implicit alias of the above isn't
problematic for that future.

-Sara

Concur.

--Larry Garfield

Hi Larry,

Sure, but how often is that an actual description of what the code
accepts? I... cannot actually envision what code would actually accept
that mess. :-)

For example the recently added get_debug_type() function does, along with
dozens of internal functions. Besides messy code, I'm sure that there are
legitimate use-cases for the mixed type in user-land as well.

use mixed = null|bool|int|float|string|array|object|resource;

use scalar = null|bool|int|float|string;
use number = int|float;

I'm really not a fan of type aliases (at least user-land ones), but I also
agree with Sara that these 3 "global" aliases would come handy. Actually, I
was considering to also propose "scalar" and "number" in a later RFC.

Cheers,
Máté

With union types and stringable already on the way, I'm not sure what other non-hypothetical use cases would still be that fugly that you'd now need to fall back to mixed.

For instance:

• the parameter of [a wrapper around] gettype() or an is_* function
• the return of [a generic implementation of]
  ArrayAccess::offsetGet() or Iterator::current(), or of a userland
  array_value_first() or array_value_last() function

To me, especially the return type declaration can be useful to ensure
that [every code path of] the implementation returns a value.

--
Guilliam Xavier

I... cannot actually envision what code would actually accept that mess. :-)

var_dump() would be one example. Also caches that can store any
userland value would be another reasonably common use.

The general pattern is when you're handling someone else's 'data' and
have no restrictions on what type that data should be. That's actually
the use-case that prompted me to help draft this RFC.

now that we have Union types what places are
there where the currently available type declarations are insufficient?

A type that explicitly allows any type is more forwards compatible
than writing out a union type.

Compare this:

var_dump( mixed $expression [, mixed $... ] ) : void

to:

var_dump( null|bool|int|float|string|array|object|resource $expression
[, null|bool|int|float|string|array|object|resource $... ] ) : void

If/when we add an 'enum' type that is not a child type of any of the
current types, the signature of that function doesn't need to change
if it uses mixed, rather than the written out union type.

Also, the 'fitting on a line' problem.

cheers
Dan
Ack

On Tue, Apr 21, 2020 at 11:10 AM Côme Chilliet
come.chilliet@fusiondirectory.org wrote:

Le lundi 20 avril 2020, 09:15:24 CEST Sara Golemon a écrit :

use mixed = null|bool|int|float|string|array|object|resource;
use scalar = null|bool|int|float|string;

I’m wondering if null should maybe be left out of these, since ?mixed and ?scalar can be used for this?

For mixed, this has been discussed several times, it's defined as the
union of all value types (void aside), including null, according
to its usage in phpDoc (and in Hack, which also has a nonnull type
such that mixed is equivalent to ?nonnull, cf
https://docs.hhvm.com/hack/types/nullable-types).

For scalar, I already replied
(https://externals.io/message/109715#109723) that it should not
include null indeed (according to
https://www.php.net/manual/en/language.types.intro.php and
https://www.php.net/manual/en/function.is-scalar.php).

--
Guilliam Xavier

I'm not as strongly against adding "mixed" to the language as Bob, but I'm
not convinced I'd ever bother using it.

I'm opposed to the use mixed in codebases – I try as best I can to remove
it from any code I come across, and a static analysis tool I've built flags
the use of mixed types whenever a more specific type is preferable. I even
have an opt-in website devoted to tracking the percentage of non-mixed
types in open-source projects, e.g.
https://shepherd.dev/github/sebastianbergmann/phpunit

Nevertheless, I think mixed should be available as a type hint for the
extreme cases mentioned in this thread (e.g. serialisation). A type system
without an explicit mixed type feels incomplete to me.

Hello,

Is there any update on the RFC? Given that there isn't much discussion and 2
weeks have passed, I believe it's safe to move this into a voting phase.

Best regards,
Benas Seliuginas

I personally would stick to mixed. It's used extensively in the official PHP
documentation and has grown with the language. Heck, even static analysis tools
and billions of PHPDoc comments (e. g. Laravel, CakePHP, Yii) use mixed type.
Switching to any just doesn't feel right.

Oh and well, I also think that mixed makes more sense.

Best regards,
Benas Seliuginas

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Actually,

Really had to laugh, reading your previous and then this mail :-)

I forgot that for proper generics implementations, collections etc. will obviously need to specify "allowing any type". As such the introduction of mixed is pretty much necessary.
As in class Foo<A, B> { … } $foo = new Foo<mixed, int>;
As such, I'm actually in favor of introducing it.

Re-quote:

"allowing any type"

That would make the case for theany type instead of mixed; IMHO much
more clear.

• Markus

Hey moliata,

Actually, it's not quite possible to declare a mixed type using union
types given that it's not possible to make properties as callable (please
take a look at my "Typed callable properties" post in the mailing list). As
such, if we wanted to make a property hold a callable, we would have to
fallback to just not using a type hint at all.

Correct me if I'm wrong but this behavior is addressed in the RFC and we
can pass callables to properties that are declared as mixed, right?

The only limitation right now is resource: callable is always either an
array, a string or an object that implements __invoke, so
callable is a subtype of the union type mentioned few posts above.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/