> > >> 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 >
Hello Nikita, Sara, Stan I agree with you that mixed in our current type system would be missused by those that want to document more than one type. So, the best to do would be to wait for a `union type` system in PHP, and than merge this feature to really document that a function accepts anything? Thanks, -- Gabriel Caruso
