rfc:nullsafe_calls

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:nullsafe_calls [2014/12/09 22:12] jwatzmanrfc:nullsafe_calls [2020/08/03 10:09] (current) – Move RFC to obsolete ilutov
Line 3: Line 3:
   * Date: 2014-12-09   * Date: 2014-12-09
   * Author: Josh Watzman (jwatzman@fb.com), Drew Paroski   * Author: Josh Watzman (jwatzman@fb.com), Drew Paroski
-  * Status: Draft+  * Status: Obsolete
   * First Published at: https://wiki.php.net/rfc/nullsafe_calls   * First Published at: https://wiki.php.net/rfc/nullsafe_calls
  
 ===== Introduction ===== ===== Introduction =====
 +**The RFC has been returned to draft stage after discussion on internals in order to figure out how to deal with short circuiting. See the "open issues" section below. The rest of the RFC currently stands as originally submitted to internals.**
 +
 This RFC proposes a new operator, the "nullsafe" operator ''<nowiki>?-></nowiki>'', which allows safe chaining of method calls. This is useful to easily propagate errors forward to the end of a computation which should fail if any of its sub-computations should fail. This RFC proposes a new operator, the "nullsafe" operator ''<nowiki>?-></nowiki>'', which allows safe chaining of method calls. This is useful to easily propagate errors forward to the end of a computation which should fail if any of its sub-computations should fail.
  
Line 82: Line 84:
 ===== Open Issues ===== ===== Open Issues =====
 Make sure there are no open issues when the vote starts! Make sure there are no open issues when the vote starts!
 +
 +==== Short Circuit ====
 +The behavior for (not) short circuiting argued for above is not clearly the right behavior. There are actually at least //three// meaningful possibilities here. I'm currently investigating implementation feasibility in both PHP7 and in HHVM, as well as generally thinking about what the right thing to do is, and will bring the discussion back up on internals once I've got my thoughts together better.
 +
 +As a quick preview, the three options can be seen as to how to desugar the following code. I'm not going to argue for or against any of them yet, just show what the range of possibilities are. (I also haven't extensively looked at the following examples, they might have errors or just not make sense, I need more time to put this together properly, dumping here for completeness only, please wait for the full revised proposal to internals :))
 +
 +<PHP>
 +$r = $x?->a(f())->b(g());
 +</PHP>
 +
 +=== Option 1: no short circuit ===
 +Arguments are evaluated even if we are doing the nullsafe call on null.
 +
 +<PHP>
 +$_tmp1 = f();
 +$_tmp2 = g();
 +$_tmp3 = $x === null ? null : $x->a($_tmp1);
 +$r = $_tmp3->b($_tmp2);
 +</PHP>
 +
 +=== Option 2: one-level short circuit ===
 +Arguments are not evaluated if we are doing the nullsafe call on null. The nullsafe behavior only applies to the single function call where the nullsafe operator is used.
 +
 +<PHP>
 +$_tmp1 = $x === null ? null : $x->a(f());
 +$r = $_tmp1->b(g());
 +</PHP>
 +
 +=== Option 3: full short circuit ===
 +Arguments are not evaluated if we are doing the nullsafe call on null. The nullsafe behavior applies to all calls chained after the nullsafe operator.
 +
 +<PHP>
 +$r = $x === null ? null : $x->a(f())->b(g());
 +</PHP>
  
 ===== Unaffected PHP Functionality ===== ===== Unaffected PHP Functionality =====
rfc/nullsafe_calls.1418163133.txt.gz · Last modified: 2017/09/22 13:28 (external edit)