Re: Re: [PHP-DEV] [RFC] Mixed type

On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <barney@redmagic.org.uk> wrote: > > The union of all other types is the top type, but I think as used in phpDoc > mixed is often really a dynamic type, rather than a top type. > > The top type (e.g. Typescript's 'unknown') is the supertype of all other > types, > while the dynamic type (e.g. Typescripts 'any') is simultaneously a > supertype > and a subtype of all other types. In Typescript (statically typed), both any and unknown are "supertype", but the former basically disables compile-time type checking (and opens for runtime errors) while the latter requires you write type checks/assertions. I guess undefined would be the actual "subtype". (By the way, unlike PHP, Typescript considers void a data type, i.e. you can have a "void variable" and assign it the value undefined.) Anyway, <https://docs.phpdoc.org/latest/guides/types.html> defines mixed as "A value with this type can be literally anything; the author of the documentation is unable to predict which type it will be" (even if some also use it where a union of a subset of types would be more accurate). > Taking a random example, arguments to str_replace documented as mixed > accept string|array and not anything else. Indeed, <https://www.php.net/manual/en/language.pseudo-types.php#language.types.mixed> currently says that, in the PHP documentation, "mixed indicates that a parameter may accept multiple (but not necessarily all) types", and gives two examples: <https://www.php.net/manual/en/function.gettype.php> is accurate, but <https://www.php.net/manual/en/function.str-replace.php> IMO should just use string|array rather than mixed (that's already the case in <https://github.com/php/php-src/blob/master/ext/standard/basic_functions.stub.php#L649-L655>). > So maybe the LSP rules shouldn't apply as described in the RFC to mixed. If > str_replace was a class method it might be OK for a subclass to change the > param type to e.g. array|string|int. > > That would leave scope for adding a real top type in a later RFC. I'd rather have the docs "fixed" (but I suspect str_replace is not the only place where mixed is used in an "approximate" fashion). mixed as defined by this RFC (i.e. equivalent to the currently-impossible-to-write union of all primitive types, including resource and null [but not void that is not a data type]) is LSP-conformant. Regards, -- Guilliam Xavier