PHP RFC: instanceof improvements
- Version: 1.0
- Date: 2020-05-17
- Author: Max Semenik, maxsem.wiki@gmail.com
- Status: Withdrawn
- First Published at: http://wiki.php.net/rfc/instanceof_improvements
Introduction
As currently implemented, the instanceof
operator is inconsistent.
var_dump(new MyClass instanceof MyClass); // true
So far so good? What if we tried to use a scalar type? They can be specified as parameter types just like class names, right?
$x = 123; var_dump($x instanceof int); // false, right hand side is always treated as a class name
Proposal
Make instanceof
support non-object types:
var_dump('foo' instanceof string); // true var_dump('foo' instanceof ('string')); // true $type = 'string'; var_dump('foo' instanceof $type); // true
Types to support
This proposal covers only concrete scalar types int
, float
, string
, bool
and null
; as well as compound types array
, object
, callable
and iterable
. Other types are intentionally omitted:
mixed
is pointless because there are easier ways to produce an expression always evaluating to true than$something instanceof mixed
.void
is kinda obvious, but I'm mentioning it just to be thorough.
All attempts to check against these types would evaluate to false
(just as currently) and produce warnings in 8.1, upgraded to fatals in 8.2.
resource
is not available as a parameter type and is on its way out, so it will be unaffected by this RFC and treated as a class name, available for userspace to use.
Legacy type aliases
There are several legacy types, supported only for typecasts: (integer)
, (double)
, (boolean)
and (binary)
. They have never worked for any other situations: e.g. the first parameter of function f(integer $x)
is interpreted as a class called integer
, we even started issuing warnings in such situations since 8.0. I propose to extend this kind of treatment to instanceof
too, issuing the same warning.
Constant expressions on the left hand side
The current implementation has a shortcut where if there is a constant expression to the left of instanceof
, the result is hardcoded as false, since the operator supports only class names on the right and constant expressions can't produce objects. This raises a question: how should be Captain Obvious cases like 123 instanceof int
be treated? What about slightly less obvious cases like 123 instanceof $typeName
? For comparison, I've checked two languages that have approaches to OOP similar to PHP:
- In Java, a variable is required on the left side of
instanceof
. All types of expressions are disallowed. - In C#, constant expressions to the left of
is
produce a correct result but a compiler warning is issued. - None of these support type names as strings, so the latter use case has no direct analogs.
I can see two possibilities why such constructs might appear in code:
- An clueless developer trying to achieve with
123 instanceof $type
something for which$type === “int”
is a better solution. - A code generator went astray and generates something dubious.
Considering this, I don't think that adding support for constant expressions on LHS would do our end users any good. I propose to continue shortcutting such cases to false (just to make sure they don't rely on this) and additionally let the developers know they're doing something wrong with E_COMPILE_WARNING
. Upgrade the warning to error in 9.0.
Backward Incompatible Changes
This proposal doesn't introduce new syntax, it only affects how some existing code could work by making the operator in some cases return true instead of false or throw warnings. However, since the affected use cases currently don't work (in a sense that they don't produce the result one would expect), existing code to be affected by this should be negligibly hard to come by.
Proposed PHP Version(s)
PHP 8.1.
RFC Impact
To SAPIs
None.
To Existing Extensions
Don't see a reason why they should.
To Opcache
None.
Open Issues
Make sure there are no open issues when the vote starts!
Unaffected PHP Functionality
Anything not related to instanceof
.
Future Scope
I'm currently pondering about extending type casts which would also improve type system and make syntax more consistent, but it's currently brewing in my head and I'm not going to let it out just yet.
Proposed Voting Choices
Accept this RFC (y/n, 2/3 majority required)?
Patches and Tests
* WIP patch: https://github.com/php/php-src/pull/6694
Implementation
After the project is implemented, this section should contain
- the version(s) it was merged into
- a link to the git commit(s)
- a link to the PHP manual entry for the feature
- a link to the language specification section (if any)
References
Links to external references, discussions or RFCs
Rejected Features
Keep this updated with features that were discussed on the mail lists.