rfc:allow-void-variance

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:allow-void-variance [2019/02/04 02:53] – wesnetmorfc:allow-void-variance [2019/02/04 07:48] (current) – wesnetmo
Line 1: Line 1:
-====== PHP RFC: Allow void override ======+====== PHP RFC: Allow void return type variance ======
   * Version: 1.0   * Version: 1.0
   * Date: 2019-02-04   * Date: 2019-02-04
Line 8: Line 8:
 ===== Introduction ===== ===== Introduction =====
  
-This RFC proposes to change ''void'' 's behavior in class methods, because the current behavior resulted to cause more annoyance than benefit. What is proposed is backward compatible and in accordance with the goals of the previous RFC; it eliminates pointless restrictions.+This RFC proposes to change in part ''void'' 's behavior in class methods; the current behavior is causing more annoyance than benefit and is probably too restrictive regardless. What is proposed here is backward-compatible and in accordance with the goals of the previous ''void'' RFC.
  
 ===== Rationale ===== ===== Rationale =====
  
-The intent of ''void'' should be simply making clear to the reader that the function does not return anything useful, and that any attempt to use the returned value should be considered an invalid operation. It shouldn't do more than that, but currently it also denies methods to be overridden with different types in subclasses. +**The intent of ''void'' should be simply making clear to the reader that the function does not return anything useful, and that any attempt to use the returned value should be considered an invalid operation.** 
 + 
 +It shouldn't do more than that, but currently it also denies methods to be overridden with different types in subclasses. 
  
 <code php> <code php>
Line 28: Line 30:
 </code> </code>
  
-This should be allowed, because it is causing discontent among users, and, most importantly, because it achieves nothing at all.+This should be allowed because it is causing discontent among users, and, most importantly, because it achieves nothing at all apart getting in the way of the developers.
  
 <code php> <code php>
 function myFooConsumer (Foo $foo) { function myFooConsumer (Foo $foo) {
  
-   // method() is void, therefore we won't be using its return type+   // method() is void, therefore we won't be using its return value
        
    $foo->method();    $foo->method();
Line 39: Line 41:
 </code> </code>
  
-If a ''Bar'' object is passed to the function (i.e. ''myFooConsumer(new Bar())''), even if ''Bar::method()'' returns an ''array'',+If a ''Bar'' object is passed to the function (i.e. ''myFooConsumer(new Bar())''), even if ''Bar::method()'' now returns an ''array'',
 it is not breaking the code in ''myFooConsumer'', because the function ''myFooConsumer'' has no interest in the return value of it is not breaking the code in ''myFooConsumer'', because the function ''myFooConsumer'' has no interest in the return value of
 ''method()'' at all. ''method()'' at all.
Line 45: Line 47:
 Even if it's receiving a ''Bar'' object, the function was originally written to be compatible with ''Foo'' objects. Even if it's receiving a ''Bar'' object, the function was originally written to be compatible with ''Foo'' objects.
 The ''method()'' can return anything, or nothing at all, but ''myFooConsumer'' just does not care about it. The ''method()'' can return anything, or nothing at all, but ''myFooConsumer'' just does not care about it.
-For this reason, it is a pointless restriction to disallow ''void'' to be changed to a type in child classes.+ 
 +For this reason adding a type to ''void'' in subclasses is not an invalid operation, and denying it is a pointless restriction. Changing from ''void'' to something else is probably a bad idea, but PHP should not enforce ''void'' in subclasses just on that basis.
  
 ===== Proposal ===== ===== Proposal =====
  
-This RFC proposes to allow ''void'' to be changed to any type or mixed in sub classes.+This RFC proposes to allow ''void'' to be changed to any type (including ''mixed'') in sub classes.
 The rest of the current behavior of ''void'' is preserved. The rest of the current behavior of ''void'' is preserved.
  
-A ''void'' return's inheritance would work exactly like ''mixed''. +A ''void'' return's inheritance would work exactly like ''mixed''; that is, the following methods follow the very same covariance rules:
- +
-That is, the following methods follow the very same covariance rules:+
  
 <code php> <code php>
Line 91: Line 92:
 </code> </code>
  
-This is not technically invalid since ''mixed'' includes ''null'', but it certainly feels "not LSP-valid" and it's therefore disallowed by this RFC.+This is technically not invalid since ''mixed'' includes ''null'', but it certainly feels "not LSP-valid" and it's therefore disallowed by this RFC. 
 + 
 +And, more obviously, also the following is disallowed: 
 + 
 +<code php> 
 +class Foo{ 
 +    function method (): void   {} 
 +} 
 + 
 +class Bar extends Foo{ 
 +    function method (): string {} // ok 
 +} 
 + 
 +class Baz extends Bar{ 
 +    function method (): void   {} // error: can't go back to void 
 +} 
 +</code> 
 + 
 +===== Precedents in other languages ===== 
 + 
 +TypeScript does this (are there other languages?).
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 104: Line 125:
  
 ===== References ===== ===== References =====
 +
 +https://externals.io/message/104091 discussion
  
  
rfc/allow-void-variance.1549248786.txt.gz · Last modified: 2019/02/04 02:53 by wesnetmo

Page Tools