Re: [RFC] Mixed type

Nikita, I think we'll need the mixed type-hint in any case if we're to move ahead with generics? On Sat, Jun 30, 2018 at 10:30 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Sat, Jun 30, 2018 at 10:17 PM, Sara Golemon <pollita@php.net> wrote: > >> On Sat, Jun 30, 2018 at 3:08 PM, Stanislav Malyshev <smalyshev@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