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
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-typehintThe 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
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-typehintThe 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
Hi!
I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehintThe 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
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
I'd like to propose and discuss Mixed Typehint RFC for PHP 7.3:
https://wiki.php.net/rfc/mixed-typehintThe 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.
WithI'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
mixed,
it should be easy to eliminate this inconsistencyThere'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
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
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
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-typehintThe 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
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.
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.
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.
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-typehintThe 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
Perhaps this is the same reason why we add "public" keyword, even
though a member is implicitly public by default.
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.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.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.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-typehintThe 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
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".
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.
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.
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/genericsNo. Work is quietly being done on parameterized types (aka generics) here:
https://github.com/morrisonlevi/php-src/tree/parameterized_traitsThere 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. Ouris_scalarfunction
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.
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.
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
For correctness:
callableis not the unionstring | array | objectbecause 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).
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.
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:
callableis not the unionstring | 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.
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).
The developer forgot the type constraint if there is no type constraint in:
- the code
- the DocBlock
This is a simple rule that you can already adopt without any changes to
the language. The thing is that mixed is not required at all at the
moment PHP supports more sophisticated type constructs. As I said
earlier, pursue them, not this.
PS: It's interesting how people fail to see the power of union and
intersection. This is currently happening on the Kotlin side too.
A simple example for a union type was already given: string|int.
Although in this case I would argue that anything that is convertible to
a hash (e.g. Hashable as found in php-ds) and ensures an equivalence
relation (not partial like float) should be usable as a key in an
associative array. The introduction of dedicated types for this is
definitely required in the language. That being said, union types are
usually of interest if you are interacting with some library code that
you cannot change (e.g. add interfaces to an existing type). Of course,
one could argue that the introduction of dedicated interfaces in your
own codebase plus adapters is the way to go but this requires much more
effort than the in-place union declaration.
Discriminating unions would be much nicer but that is something a proper
enum impl should cover.
Intersection is a whole other beast that is actually more powerful than
the simple unions we know from PhpDoc. Consider the following example:
interface Writer
interface Reader
interface Seekable
interface AutoCloseable
interface Closeable
We could now continue and provide ReadableWriter, SeekableWriter,
SeekableReadableWriter, ... but this already gets out of hand. An
intersection on the other hand allows you to define exactly the features
you require:
fn f(Closeable & Seekable & Writer writer)
This can of course be provided with a generics impl which would probably
make the parsing impl simpler:
fn f<T: Closeable + Seekable + Writer>(T writer)
--
Richard "Fleshgrinder" Fussenegger
Am 19.12.2017 um 19:19 schrieb Fleshgrinder:
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).The developer forgot the type constraint if there is no type constraint in:
- the code
- the DocBlock
This is a simple rule that you can already adopt without any changes to
the language. The thing is that mixed is not required at all at the
moment PHP supports more sophisticated type constructs. As I said
earlier, pursue them, not this.PS: It's interesting how people fail to see the power of union and
intersection. This is currently happening on the Kotlin side too.A simple example for a union type was already given:
string|int
i see the power and have hundrets of definitions where i would add such
hints instead nothing if it would be supported
but that's a different thing and both don't collide
"It's a simple alias for the current behavior of no type and is fully
interchangeable" from this RFC about mixed is completly unrelated to
union types
but that's a different thing and both don't collide
It's not a different thing, that's what I try to tell you. They do not
collide, of course not, but having the others is going to make mixed
useless.
In other words: if there is no type left to constraint to, it must be
the top type. (Note that we already have the ability to constraint to
the bottom type void.)
Other languages invest quite some time into getting rid of annotating
their top types (and type inversion) and we already have this
functionality and you (not you in person but the collective here asking
for it) want to introduce it. Stanislav is right, this type would be
there for no technical reason.
It is only for cosmetics or maybe to allow people to say "my codebase is
fully type constrained". Which is literally a meaningless statement.
--
Richard "Fleshgrinder" Fussenegger
Am 19.12.2017 um 21:53 schrieb Fleshgrinder:
but that's a different thing and both don't collide
It's not a different thing, that's what I try to tell you. They do not
collide, of course not, but having the others is going to make mixed
useless.In other words: if there is no type left to constraint to, it must be
the top type. (Note that we already have the ability to constraint to
the bottom type void.)Other languages invest quite some time into getting rid of annotating
their top types (and type inversion) and we already have this
functionality and you (not you in person but the collective here asking
for it) want to introduce it. Stanislav is right, this type would be
there for no technical reason.It is only for cosmetics or maybe to allow people to say "my codebase is
fully type constrained". Which is literally a meaningless statement.
yes, it's mostly cosmetic (frankly even the OP statet this in the
initial mail) but if that comes witout a noticebale price to pay why not?
"It's a simple alias for the current behavior of no type and is fully
interchangeable" sounds like it could even be optimized out at compile
time of the script - so "you don't need it" is not much compelling for me
yes, it's mostly cosmetic (frankly even the OP statet this in the
initial mail) but if that comes witout a noticebale price to pay why not?"It's a simple alias for the current behavior of no type and is fully
interchangeable" sounds like it could even be optimized out at compile
time of the script - so "you don't need it" is not much compelling for me
Adding that optimization step is already more effort than not
introducing it in the first place, don't you agree?
Seriously, I am neutral on the topic in itself. Fact is that it is an
unnecessary change from a technical perspective and it will not bring
PHP forward in adopting a sound type system. I just wanted to show
support for Stanislav's position because he is simply right from a
technical point of view (which imho is more important in language design).
There is no argument against the "we like it pretty".
--
Richard "Fleshgrinder" Fussenegger
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-typehintThe 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/2603Please 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.
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.
Am 20.12.2017 um 13:56 schrieb Sebastian Bergmann:
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
[...]
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.
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".
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.