rfc:instanceof_improvements

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
Next revisionBoth sides next revision
rfc:instanceof_improvements [2020/05/19 18:55] – created maxsemrfc:instanceof_improvements [2021/03/08 17:40] maxsem
Line 7: Line 7:
  
 ===== Introduction ===== ===== Introduction =====
-The elevator pitch for the RFCThe first paragraph of this section will be slightly larger to give it emphasisplease write good introduction.+As currently implemented, the `instanceof` operator is inconsistent. 
 +<code php> 
 +var_dump(new MyClass instanceof MyClass); // true 
 +</code> 
 +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? 
 +<code php> 
 +$x = 123; 
 +var_dump($x instanceof int); // false, right hand side is always treated as class name 
 +</code>
  
 ===== Proposal ===== ===== Proposal =====
-I'd like to propose to modify ''instanceof'' to support non-object types, as well as expressions on the right:+Make ''instanceof'' support non-object types:
 <code php> <code php>
-'foo' instanceof string            // true +var_dump('foo' instanceof string);      // true 
-'foo' instanceof 'string'          // true +var_dump('foo' instanceof ('string'));  // true 
-$logger instanceof "{$this->loggerType}Logger" +$type = 'string'; 
-$foo instanceof SomeClass::class   // kinda silly - but why the heck not? +var_dump('fooinstanceof $type);       // true
-$foo instanceof $someObject::class // a less silly variation +
 </code> </code>
 +
 +==== 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 ====
 +
 +
 +==== 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.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 24: Line 48:
  
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
-PHP 8.0.+PHP 8.1.
  
 ===== RFC Impact ===== ===== RFC Impact =====
rfc/instanceof_improvements.txt · Last modified: 2022/04/18 10:51 by ilutov