rfc:nullsafe_calls
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:nullsafe_calls [2014/10/22 23:42] – jwatzman | rfc:nullsafe_calls [2020/08/03 10:09] (current) – Move RFC to obsolete ilutov | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: Nullsafe Calls ====== | ====== PHP RFC: Nullsafe Calls ====== | ||
- | * Version: | + | * Version: 1.0 |
- | * Date: 2014-10-22 | + | * Date: 2014-12-09 |
* Author: Josh Watzman (jwatzman@fb.com), | * Author: Josh Watzman (jwatzman@fb.com), | ||
- | * Status: | + | * Status: |
* First Published at: https:// | * First Published at: https:// | ||
===== 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" | ||
+ | |||
This RFC proposes a new operator, the " | This RFC proposes a new operator, the " | ||
Line 42: | Line 44: | ||
} | } | ||
</ | </ | ||
+ | |||
+ | ==== Short Circuit ==== | ||
+ | If '' | ||
+ | |||
+ | This is done because it parallels what the ''< | ||
+ | |||
+ | It's worth noting that this point has deep implications for the implementation, | ||
==== Implications ==== | ==== Implications ==== | ||
Line 48: | Line 57: | ||
* If '' | * If '' | ||
* If '' | * If '' | ||
- | * If '' | ||
==== Prior Art ==== | ==== Prior Art ==== | ||
* C#, CoffeeScript, | * C#, CoffeeScript, | ||
+ | * Haskell has the "maybe monad", | ||
* Hack has already implemented a proposal identical to this one. | * Hack has already implemented a proposal identical to this one. | ||
===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== | ||
- | What breaks, and what is the justification for it? | + | Due to an implementation detail, this decreases the maximum number of arguments a function can be called with from '' |
+ | |||
+ | This is just a technicality... all of my attempts to actually hit that limit put my machine into swapdeath long before I got close :-P | ||
+ | |||
+ | See also "RFC Impact To Existing Extensions" | ||
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
- | This is proposed for the next major version of PHP, currently PHP 7. | + | PHP7. |
===== RFC Impact ===== | ===== RFC Impact ===== | ||
- | ==== To SAPIs ==== | ||
- | Describe the impact to CLI, Development web server, embedded PHP etc. | ||
- | |||
==== To Existing Extensions ==== | ==== To Existing Extensions ==== | ||
- | Will existing | + | Extensions have access to an opline' |
- | ==== To Opcache ==== | + | If this impact |
- | It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP. | + | |
- | + | ||
- | Please explain how you have verified your RFC's compatibility with opcache. | + | |
==== New Constants ==== | ==== New Constants ==== | ||
- | Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation. | + | Nothing accessible from outside |
- | + | ||
- | ==== php.ini Defaults ==== | + | |
- | If there are any php.ini settings then list: | + | |
- | * hardcoded default values | + | |
- | * php.ini-development values | + | |
- | * php.ini-production values | + | |
===== 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' | ||
+ | |||
+ | <PHP> | ||
+ | $r = $x? | ||
+ | </ | ||
+ | |||
+ | === 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-> | ||
+ | $r = $_tmp3-> | ||
+ | </ | ||
+ | |||
+ | === 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-> | ||
+ | $r = $_tmp1-> | ||
+ | </ | ||
+ | |||
+ | === 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-> | ||
+ | </ | ||
===== Unaffected PHP Functionality ===== | ===== Unaffected PHP Functionality ===== | ||
- | This RFC does not change any existing PHP behavior, including the ''< | + | This RFC does not change any existing PHP behavior, including the ''< |
===== Future Scope ===== | ===== Future Scope ===== | ||
Line 94: | Line 129: | ||
===== Patches and Tests ===== | ===== Patches and Tests ===== | ||
- | * php-src: I have a scratch | + | * php-src: I have a branch at https:// |
- | * PHP spec: nothing | + | * PHP spec: not yet, but will do if the RFC is accepted. |
* PHP docs: import Hack's documentation when they add it: https:// | * PHP docs: import Hack's documentation when they add it: https:// | ||
rfc/nullsafe_calls.1414021366.txt.gz · Last modified: 2017/09/22 13:28 (external edit)