On 23.04.2020 at 11:26, Guilliam Xavier wrote: > On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <bar...@redmagic.org.uk> > wrote: > >> 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).
Besides that PhD does not yet properly support union types[1], it's not quite as simple. array|string would cause failure in strict mode if, for instance, an int is passed; however, str_replace() has no issues with this[2]. This is the reason why the stub file declares the types of $search and $replace only in the doc block comment. [1] <https://github.com/php/phd/pull/25> [2] <https://3v4l.org/R7Iac> -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
