update optional chaining RFC 0018

* typo fix on example code;
* fix paragraph that approaches CPAN emulation of the feature;
* move mention of optional chains in string interpolation / regexes
  from "Open Issues" to "Future Scope", effectively addressing all
  open issues (and added nod to template literals);.
* expand "rejected ideas" FAQ to include rationale over lexical pragmas
  and related ideas, while also deepening the explanation of why it
  should be explicit.

Author: garu

rfcs/rfc0018.md

@@ -114,9 +114,10 @@ those scenarios (but see 'Open Issues' below).
 Static tooling may confuse the new operator with a syntax error until
 updated.
 
-Earlier versions of Perl could potentially emulate this feature with a CPAN
-module relying on something like XS::Parse::Infix (perl 5.14 onwards),
-though the implementation effort has not been explored.
+Because it is an infix operator with special/reserved characters and short-
+circuiting, this feature cannot be easily emulated as-is with a CPAN module.
+XS::Parse::Infix could help, but even that only works on a patched version of
+perl.
 
 ## Security Implications
 
@@ -131,7 +132,7 @@ Expected common uses:
 
 ```perl
     # $val = defined $foo && defined $foo->{bar} ? $foo->{bar}[3] : ();
-    $val = $foo?->{bar}?->[3};
+    $val = $foo?->{bar}?->[3];
 
     # $tmp = defined $obj ? $obj->m1 : (); $val = defined $tmp ? $tmp->m2 : ();
     $val = $obj?->m1?->m2;
@@ -225,6 +226,13 @@ The equivalence, in this case, would be:
 While this is the actual goal, a first version of the operator could ignore
 this and stick with named variables.
 
+Also, optional chains under string interpolation and regular expressions
+could be enabled in the future, hidden behind a feature flag to prevent
+backwards compatibility issues, much like what was done with `postderef_qq`.
+However, due to the nature of the operator, the need for its usage on those
+contexts should not be too big - and even then it can be mitigated by efforts
+such as Template Literals (RFC0019).
+
 ## Rejected Ideas
 
 The idea of a similar operator has been going on and off the p5p list since
@@ -238,6 +246,15 @@ arose in the past, and the design decisions that led to this particular RFC.
 Besides being shorter, the optional chain will NOT silence actual errors
 coming from a method, or from a defined value that is not a ref.
 
+* Why not just a lexical pragma?
+
+Providing the definedness check on arrow operators via a pragma is
+unfortunately not good enough as it (a) doesn't give you enough granularity
+and control of your chain in, say, `$o?->m1->m2?->m3;`; (b) promotes
+[action at a distance](https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming));
+and (c) even if only enabled lexically, provides little to no gain in terms
+of reading/writing statements as `{no X; $o->m}` vs `$o->m if defined $o`.
+
 * Why is the token `?->` and not "X"
 
 There have been a lot of different proposals for this operator over the
@@ -266,9 +283,10 @@ issue of having to add a lot of repetitive and error-prone boilerplate tests
 on an entire chain individually, and nothing else.
 
 While we could (hypothetically) try to expand this notion to other operators
-(e.g. `?=`, `?=~`, etc), the benefit of doing so is unclear at this point,
-and would require a lot of effort picking appart which operators should
-and shouldn't include the "optional" variation [4].
+(e.g. `?=`, `?=~`, etc) or even explore related ideas (such as a non-null
+assertion operator like `!->`), the benefit of doing so is unclear at this
+point, and would require a lot of effort picking appart which operators
+should and shouldn't include the "optional" variation [4].
 
 * Why definedness and not truthfulness? Or 'ref'? Or 'isa'?
 
@@ -280,13 +298,26 @@ treated as package/class names), so we cannot reliably test for 'ref'
 without making things really convoluted with assumptions, rules and
 exceptions for each type of data.
 
-* Can we have implicit `?->` after its first use? Have it flip/flop against
-`->`?
+* Can we have implicit `?->` after its first use? Or have it flip/flop
+against `->` on a chain?
 
-The idea is for `?->` to always be explicit, since it is testing the
-lefhand side of the expression. Making the operator change how explicit or
-implicit dereference works in the rest of the expression could lead to
-confusion and bugs.
+The proposed optional chain short-circuit is not a bugfix of the arrow
+dereference's behaviour, it's a shortcut to a common (and error prone)
+construct that happens when the developer wants to achieve just that. Short-
+circuiting instead of runtime exceptions could hide bugs, so we require
+developers to make a conscious and explicit choice every time they want this
+feature in any part of the chain. It may be a little bit tedious to
+write longer optional chains, but it will surely be easier to read,
+understand and spot logic errors if the operator is explicit.
+
+This decision is endorsed by the fact that all implementations of the
+null-safe / optional chain operator in other languages also require it to be
+explicit. Besides, evidence suggests less than 20% of the usage will chain
+more than two calls[5].
+
+A possible alternative to make the optional chain "greedy" could be the
+addition of yet another operator (like `??->`), but they are beyond the scope
+of this RFC and should be explored in another draft, if the need arises.
 
 * Why not other identity values according to context? Like '' when
 concatenating strings, 0 on addition/subtraction and 1 on
@@ -302,9 +333,7 @@ the same results, e.g.: `"value is: " . ($ref?->{val} // '')`.
 
 ## Open Issues
 
-Optional chains under string interpolation and regular expressions could be
-enabled in the future, hidden behind a feature flag to prevent backwards
-compatibility issues, much like what was done with `postderef_qq`.
+None.
 
 ## References:
 
@@ -314,6 +343,7 @@ compatibility issues, much like what was done with `postderef_qq`.
 4. Python's proposal, and the ongoing discussion around it, are a noteworthy
    external example of the consequences of trying to add that logic to many
    different operators. https://peps.python.org/pep-0505
+5. https://github.com/alangpierce/coffeescript-soak-stats
 
 ## Copyright