Feature #11813
closedExtend safe navigation operator for [] and []= with syntax sugar
Description
Now we have the safe navigation operator &.
. But this cannot be used with syntax sugar form of the methods []
and []=
, which are more frequent than their ordinary forms of method call. For example, when a
can be either an array or nil
, we can do:
a &.[](3)
a &.[]= 2, :foo
but we cannot do:
a &.[3]
a &.[2] = :foo
It would be nice if we can extend the use of &.
to cover syntactic sugar as above.
Updated by yugui (Yuki Sonoda) almost 9 years ago
- Assignee set to matz (Yukihiro Matsumoto)
Updated by usa (Usaku NAKAMURA) almost 9 years ago
IMO, we can write &.
only for replacement of .
.
As you know, ary.[idx]
is not valid, then ary&.[idx]
should not be valid, too.
Updated by nobu (Nobuyoshi Nakada) almost 9 years ago
Usaku NAKAMURA wrote:
IMO, we can write
&.
only for replacement of.
.
As you know,ary.[idx]
is not valid, thenary&.[idx]
should not be valid, too.
That is same as matz's opinion and the reason it was removed at r52430.
parse.y: revert lbracket
* parse.y (lbracket): remove .? before aref. [Feature #11537]
revert r52422 and r52424
I don't think this proposal will be accepted.
We'll need a better notation.
Updated by yui-knk (Kaneko Yuichiro) almost 9 years ago
- Related to Bug #11618: Safe call syntax with aref or aset is added
Updated by Anonymous over 8 years ago
It seems to me that a "safe subscript operator" should simply add a &
between the receiver and the subscript operator (making a[3]
safe would mean changing it to a&[3]
), just like safe navigation adds a &
between the receiver and the method invocation operator (a.foo
=> a&.foo
).
Unfortunately, &
is also a method name and is defined for several corelib classes (bitwise AND for Fixnum
, set intersection for Array
, boolean AND for FalseClass
/NilClass
/TrueClass
). So if variable a
above were an array, a&[3]
would return the set intersection of a
and [3]
. It is true that a&.[](3)
accomplishes the desired outcome, but this involves using the subscript operator as a method name -- which obscures semantic intent.
Is it possible to define a "safe subscript operator" with simple and unique syntax?
Updated by matz (Yukihiro Matsumoto) over 8 years ago
- Status changed from Open to Rejected
Use #dig
for referencing the value.
For updating, show us use cases.
Matz.
Updated by znz (Kazuhiro NISHIYAMA) over 7 years ago
- Has duplicate Feature #13645: Syntactic sugar for indexing when using the safe navigation operator added