On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon <poll...@php.net> wrote:
> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalys...@gmail.com> > wrote: > >> Together with Michael Moravec, we’d like to announce that we are > pretending > >> to open the Mixed Type RFC (https://wiki.php.net/rfc/mixed-typehint) > next > >> Monday (02/07) and we’d like to ask you to take a look into the PR on > >> GitHub (https://github.com/php/php-src/pull/2603) and let us know if > >> there's something else to do before it. > > > > I think this is wrong. This "type" - which is not really a type, of > > course - does not add anything to the code, by definition - if you take > > it out, everything would be the same. Things like that belong in the > > documentation. Moreover, it makes the code harder to read, as the reader > > should make mental effort to discard this non-type every time it is > > mentioned, as it does not carry any information. > > > I would say that, in a world without union or intersection types, it > adds to the readability of the code by explicitly saying, "We accept > more than one type here, and we know we accept more than one type > here." This is distinct from, "We have no idea what type we accept > here." That adds to readability, it doesn't detract. > > I preface that with a mention of union/intersection types because that > seems to be the *actual* problem this RFC is attempting to cope with > while lacking the tools to do it right. I'm not super excited about > this RFC because, as you say, this information could be easily encoded > into the docblock for the function/method. Zero impact to the syntax, > same benefit for the programmer and their readability. (More benefit, > really, as docblock standards *do* permit union/intersection types. > I'm basically with Sara here. Generally the feature has some merit, but I'm sure that given our current type-system, and in particular the lack of union types, this feature will be misused to annotate parameters that do *not* accept completely arbitrary values, but where "mixed" is the best approximation we have. For that reason I would prefer to defer this addition until proper union types are supported. In that case mixed would be a shortcut for the otherwise somewhat unwieldy type of ?(bool|int|float|string|array|object|resource) (modulo the non-existence of resource...) Nikita
