Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Mixed Typehint »

[RFC] Mixed Typehint

php.internals

Michael Moravec

8 years ago
Hello internals, I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: https://wiki.php.net/rfc/mixed-typehint The purpose of this RFC is to introduce "mixed" typehint on language level to be used as a valid typehint. PHP currently forces users to not use any type in case the type is mixed/unclear. This makes code inconsistent and less explicit. With mixed, it should be easy to eliminate this inconsistency and achieve fully type hinted code. It's a simple alias for the current behavior of no type and is fully interchangeable. This is mostly cosmetic change, no BC break to user-land is involved. This RFC comes with a rather simple PR: https://github.com/php/php-src/pull/2603 Please let me know what you think or if you find anything unclear. Thanks! Michael Moravec

Michael Morris

8 years ago
On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec <php.net@majkl578.cz> wrote:
> Hello internals, > > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > https://wiki.php.net/rfc/mixed-typehint > > The purpose of this RFC is to introduce "mixed" typehint on language level > to be used > as a valid typehint.
If I'm not mistaken, "mixed" is used in documentation when a function has been overloaded to avoid needing to have documentation for all the methods. C allows overloading, and I imagine that PHP functions implemented in the engine using C are using overloading. To be honest, I'd rather see function overloading in PHP than this, but that's a massive can of worms with a lot of problems on both the implementation side and also on the usage side. Function overloading can be abused to create some rather bizarre and difficult to follow code. That said, with PHP moving to be at least a little more strict about variable types. As to the proposal itself, I see no advantage over not using a typehint at all. More on overloading: https://en.wikipedia.org/wiki/Function_overloading

lists@rhsoft.net

8 years ago
Am 19.12.2017 um 04:44 schrieb Michael Morris:
> On Mon, Dec 18, 2017 at 10:34 PM, Michael Moravec <php.net@majkl578.cz> > wrote: > >> Hello internals, >> >> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: >> https://wiki.php.net/rfc/mixed-typehint >> >> The purpose of this RFC is to introduce "mixed" typehint on language level >> to be used >> as a valid typehint. > > > If I'm not mistaken, "mixed" is used in documentation when a function has > been overloaded to avoid needing to have documentation for all the methods. > C allows overloading, and I imagine that PHP functions implemented in the > engine using C are using overloading
no, mixed is used in phpdoc comments to say "no type specified at all" when a param accepts anything and in case of "@return mixed" that it can return void, array, int..... the RFC would make phpdoc and code consistent

Stas Malyshev

8 years ago
Hi!
> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > https://wiki.php.net/rfc/mixed-typehint > > The purpose of this RFC is to introduce "mixed" typehint on language level > to be used > as a valid typehint. PHP currently forces users to not use any type in case > the > type is mixed/unclear. This makes code inconsistent and less explicit. With
I'm not sure what's the point of it. "mixed" means "any type". Not writing a type means "any type". So why waste space and add something that contributes nothing when everybody is already using the current convention and the new one does not add anything at all?
> mixed, > it should be easy to eliminate this inconsistency
There's no "inconsistency" here.
> and achieve fully type hinted code.
This is not an "achievement" - adding prefixes for the sake of all variables having prefixes that mean nothing is not an "achievement". I do not see any point in it.
-- Stas Malyshev smalyshev@gmail.com

Fleshgrinder

8 years ago
On 12/19/2017 7:32 AM, Stanislav Malyshev wrote:
> I'm not sure what's the point of it. "mixed" means "any type". Not > writing a type means "any type". So why waste space and add something > that contributes nothing when everybody is already using the current > convention and the new one does not add anything at all? >
I agree with Stanislav here, there is no point in adding this type constraint. Documenting mixed with PhpDoc was required in the past because it was not possible for documentation tools to distinguish between `@param string` and `@param mixed` because there was absolutely no type information available. This has change today, you can ensure that the tools understand your types. What is really needed are `scalar`, `number`, union types, intersection types, and all that together with generics. Note that the situation would be different if our super type (which is `mixed`) would allow for some common action, e.g. `equals`. That is not the case, hence, there is no point in constraining it. Both the super and bottom type (`void`) in PHP are totally behaviorless.
-- Richard "Fleshgrinder" Fussenegger

Niklas Keller

8 years ago
> > > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > > https://wiki.php.net/rfc/mixed-typehint > > > > The purpose of this RFC is to introduce "mixed" typehint on language > level > > to be used > > as a valid typehint. PHP currently forces users to not use any type in > case > > the > > type is mixed/unclear. This makes code inconsistent and less explicit. > With > > I'm not sure what's the point of it. "mixed" means "any type". Not > writing a type means "any type". So why waste space and add something > that contributes nothing when everybody is already using the current > convention and the new one does not add anything at all?
Why document code? It contributes nothing to the behavior of the code, well, unless you parse it as annotations. The current one isn't any convention, it's just not possible to do something else. There's nothing that explicitly allows saying "I accept all types", rather than "The type I accept is unspecifed". That said, I'm not sure myself. I guess a more complex type which can't be expressed currently (like a union type) might also use "mixed" then. Regards, Niklas

Stas Malyshev

8 years ago
Hi!
> Why document code? It contributes nothing to the behavior of the code, > well, unless you parse it as annotations.
I am not sure I understand - are you arguing for supporting "mixed" in *documentation*? Then it's already supported and there's no need for any RFC. But if you're arguing for supporting it in the code, it's useless and has nothing to do with documentation - which you'd have to write anyway.
> The current one isn't any convention, it's just not possible to do > something else. There's nothing that explicitly allows saying "I accept > all types", rather than "The type I accept is unspecifed".
There could be of course logical constructions that are not supported by the type system. "mixed" however has the accepted meaning - and that meaning is exactly the same as not specifying the type. I do not see any additional use of type that only means "unspecified type" - it looks like its sole reason is so that somebody could say "I now have lots of types in my code!" which does not seem to me a worthy goal. Types should serve a purpose, this one serves none.
-- Stas Malyshev smalyshev@gmail.com

Christian Schneider

8 years ago
Am 19.12.2017 um 09:49 schrieb Stanislav Malyshev <smalyshev@gmail.com>:
>> The current one isn't any convention, it's just not possible to do >> something else. There's nothing that explicitly allows saying "I accept >> all types", rather than "The type I accept is unspecifed". > > There could be of course logical constructions that are not supported by > the type system. "mixed" however has the accepted meaning - and that > meaning is exactly the same as not specifying the type. I do not see any > additional use of type that only means "unspecified type" - it looks > like its sole reason is so that somebody could say "I now have lots of > types in my code!" which does not seem to me a worthy goal. Types should > serve a purpose, this one serves none.
I agree, if you want to document that you code accepts mixed types you could simple write /* mixed */, i.e. a comment. If you're talking about tool support then the tool could also support this comment. Would not be unheard of either. - Chris

Michael Kliewe

8 years ago
Am 19.12.2017 um 07:32 schrieb Stanislav Malyshev:
> >> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: >> https://wiki.php.net/rfc/mixed-typehint >> >> The purpose of this RFC is to introduce "mixed" typehint on language level >> to be used >> as a valid typehint. PHP currently forces users to not use any type in case >> the >> type is mixed/unclear. This makes code inconsistent and less explicit. With > I'm not sure what's the point of it. "mixed" means "any type". Not > writing a type means "any type". So why waste space and add something > that contributes nothing when everybody is already using the current > convention and the new one does not add anything at all?
A "mixed" type hint says that it's really "mixed", and the developer who wrote that code did not forget to add a type hint. If you see a place where a type hint is missing, you don't know if it's mixed, or the developer/you missed to write the correct type hint. That's the benefit I see. I would explicitly write "mixed" everywhere in a fully type-hinted codebase, to eliminate this thought while reading: Is it really mixed, or was this place overseen and it's not mixed, but something else... Because it's optional, nobody is hurt, but some people (like me) could add this explicit information. Michael

Andreas Hennings

8 years ago
I agree with Michael Kliewe. When looking at code, I want to distinguish between: - Developer forgot to add a type hint, or it was left out for legacy / BC reasons. - The function can really return various types, at least too many for any more specific type hint. On 19 December 2017 at 04:57, lists@rhsoft.net <lists@rhsoft.net> wrote:
> no, mixed is used in phpdoc comments to say "no type specified at all" when a param accepts anything and in case of "@return mixed" that it can return void, array, int.....
I think "mixed" should not include "void". A well-written method/function either has a return value or not. It it is type-hinted as "mixed", then we should expect it to have a return value. On 19 December 2017 at 08:06, Fleshgrinder <php@fleshgrinder.com> wrote:
> What is really needed are `scalar`, `number`, union types, intersection > types, and all that together with generics.
I would like to see those too, but they are not mutually exclusive with "mixed" and should rather be discussed separately. On 19 December 2017 at 11:01, Michael Kliewe <info@phpgangsta.de> wrote:

Andreas Hennings

8 years ago
Perhaps this is the same reason why we add "public" keyword, even though a member is implicitly public by default. On 19 December 2017 at 12:34, Andreas Hennings <andreas@dqxtech.net> wrote:

Andreas Hennings

8 years ago
On 19 December 2017 at 08:06, Fleshgrinder <php@fleshgrinder.com> wrote:
> What is really needed are `scalar`, `number`, union types, intersection > types, and all that together with generics.
Do we have ongoing discussions or RFCs for those already? I know we have one for generics, which seems somehow stuck, https://wiki.php.net/rfc/generics What would "scalar" mean exactly? string+int+float? I would sometimes like a string+int, for "everything that can be an array key".

Levi Morrison

8 years ago
On Tue, Dec 19, 2017 at 4:47 AM, Andreas Hennings <andreas@dqxtech.net> wrote:
> On 19 December 2017 at 08:06, Fleshgrinder <php@fleshgrinder.com> wrote: >> What is really needed are `scalar`, `number`, union types, intersection >> types, and all that together with generics. > > Do we have ongoing discussions or RFCs for those already? > I know we have one for generics, which seems somehow stuck, > https://wiki.php.net/rfc/generics
No. Work is quietly being done on parameterized types (aka generics) here: https://github.com/morrisonlevi/php-src/tree/parameterized_traits There really isn't a lot to discuss at this stage anyway; the technical implementation is paramount.
> What would "scalar" mean exactly? string+int+float?
Scalar and number are just ways of naming certain union types which feature was already declined. Maybe a single RFC which targets both union and intersection types would pass. Our `is_scalar` function returns true for integer, float, string or boolean; a scalar type should mirror that definition: int | float | string | bool.
> I would sometimes like a string+int, for "everything that can be an array key".
This is just another named union for `string | int`.

Andreas Hennings

8 years ago
We already have other "meta" types. E.g. "callable" can be a string, an array, an object with __invoke(). A "numeric" can be float or int. A "iterable" can be an array or an traversable object. Technically you are right, my "anything that could be an array index" would be equivalent to "string|int". Personally I don't think we need every possible union, let alone intersections. I am not strictly opposed to them, but don't find them as necessary. Most well-written functions will have one return type. But there are some cases of naturally occuring union or meta types, which might deserve their own meta type name. On 19 December 2017 at 16:28, Levi Morrison <levim@php.net> wrote:

Levi Morrison

8 years ago
On Tue, Dec 19, 2017 at 10:05 AM, Andreas Hennings <andreas@dqxtech.net> wrote:
> We already have other "meta" types. > E.g. "callable" can be a string, an array, an object with __invoke(). > A "numeric" can be float or int. > A "iterable" can be an array or an traversable object.
For correctness: `callable` is not the union `string | array | object` because only certain kinds of strings, arrays, and objects are accepted.
> Personally I don't think we need every possible union, let alone intersections.
How many do we need to have for us to make the conclusion we should stop making special-cases in the engine and generalize it? In any case we are straying off-topic: this thread is about `mixed` which I would vote against. As our type-system stands it provides almost no value. If our type system ever changes and it suddenly provides value then it should be proposed at that point.

lists@rhsoft.net

8 years ago
Am 19.12.2017 um 18:30 schrieb Levi Morrison:
> In any case we are straying off-topic: this thread is about `mixed` > which I would vote against. As our type-system stands it provides > almost no value. If our type system ever changes and it suddenly > provides value then it should be proposed at that point
IMHO the wrong question, the right ones would be a) how much work is it to implement b) does it any harm c) is it maintainable and does it bring relevant maintainance cost the fact that in a sane project where you use typehints wherever it is possible that you then can distinct between forgotten typehint versus explicit statet brings a benefit for userland code while nobody is forced to use it

Andreas Hennings

8 years ago
> For correctness: `callable` is not the union `string | array | object` because only certain kinds of strings, arrays, and objects are accepted.
Correct.
> this thread is about `mixed` > which I would vote against. As our type-system stands it provides > almost no value
The argument, which I support, is that "mixed" would allow to distinguish against cases of "developer forgot to add a type hint" or "no type hint due to legacy / BC reasons". Also, with a "mixed" type hint, you know it is not "void" (this is still the same argument). On 19 December 2017 at 18:38, lists@rhsoft.net <lists@rhsoft.net> wrote:
> IMHO the wrong question, the right ones would be > > a) how much work is it to implement > b) does it any harm > c) is it maintainable and does it bring relevant maintainance cost
I think we do need to explain whether a feature "provides value", so Levi's question is not wrong. Simply "does no harm" is not enough. We just disagree on the answer, we actually do think it provides value. On 19 December 2017 at 18:30, Levi Morrison <levim@php.net> wrote:

Benoit SCHILDKNECHT

8 years ago
Le Tue, 19 Dec 2017 04:34:24 +0100, Michael Moravec <php.net@majkl578.cz> a écrit:
> Hello internals, > > I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > https://wiki.php.net/rfc/mixed-typehint > > The purpose of this RFC is to introduce "mixed" typehint on language > level > to be used > as a valid typehint. PHP currently forces users to not use any type in > case > the > type is mixed/unclear. This makes code inconsistent and less explicit. > With > mixed, > it should be easy to eliminate this inconsistency and achieve fully type > hinted code. > It's a simple alias for the current behavior of no type and is fully > interchangeable. > This is mostly cosmetic change, no BC break to user-land is involved. > > This RFC comes with a rather simple PR: > https://github.com/php/php-src/pull/2603 > > Please let me know what you think or if you find anything unclear. > > Thanks! > Michael Moravec
It would be a +1 for me. Typehinting "mixed" tells way more than no typehinting at all. Because legacy code.

Sebastian Bergmann

8 years ago
On 12/19/2017 04:34 AM, Michael Moravec wrote:
> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: > https://wiki.php.net/rfc/mixed-typehint
"mixed" is too unspecific. I understand the reasoning behind wanting "mixed": to express explicitly that a type declaration was not forgotten. I think that a "scalar" type that "groups together" bool, float, int, and string would make more sense. This would allow the expression that something is not an array, not an object, and not a resource.

lists@rhsoft.net

8 years ago
Am 20.12.2017 um 13:56 schrieb Sebastian Bergmann:
> On 12/19/2017 04:34 AM, Michael Moravec wrote: >> I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3: >> https://wiki.php.net/rfc/mixed-typehint > > "mixed" is too unspecific. I understand the reasoning behind wanting > "mixed": to express explicitly that a type declaration was not forgotten. > > I think that a "scalar" type that "groups together" bool, float, int, > and string would make more sense. This would allow the expression that > something is not an array, not an object, and not a resource
no - 'mixed' is for the same thing you have a comment "@param mixed $var" and that contains by definition array, object and resource when your method accepts any type and handles internally what to do with them what you are talking about are unions statet multiple times in this thread

Sebastian Bergmann

8 years ago
On 12/20/2017 02:17 PM, lists@rhsoft.net wrote:
> [...]
Off topic: I find it rude that you are posting to this list without providing a real name.
> what you are talking about are unions statet multiple times in this thread
No, I was not talking about union types. What I talked about could be thought of as an alias for a common use case of union types.

Andreas Hennings

8 years ago
> I think that a "scalar" type that "groups together" bool, float, int, and string would make more sense. This would allow the expression that something is not an array, not an object, and not a resource.
Why would this be an either/or? I don't mind a "scalar" type hint. But this could be a separate discussion, and is not in conflict with "mixed". On 20 December 2017 at 13:56, Sebastian Bergmann <sebastian@php.net> wrote: