Re: [RFC] Mixed type

From: Date: Thu, 23 Apr 2020 10:21:00 +0000
Subject: Re: [RFC] Mixed type
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-109805@lists.php.net to get a copy of this message
On 23.04.2020 at 11:26, Guilliam Xavier wrote: > On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <barney@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

« previous php.internals (#109805) next »