Feature #16960
Feedback regarding => in βAsβ Pattern Matching
Description
The only obstacle preventing the use of non-symbol keys in hash patterns is simply the fact that =>
is used for both Hash
es and βasβ patterns.
case x
in Integer => a, Float => b # Ambiguous
in key: Symbol => value, **rest # Poor readability
in Symbol => key => Symbol => value, **rest # ???
end
I recommend changing to something else. We can introduce the and operator &
:
case array in Float & 5 & five
five.eql? 5.0 #=> true
end
And/Or, implement another operator explicitly for βasβ patterns, say :
(otherwise only used for the ternary operation) β
case x
in Integer : a, Float : b
in key: Symbol : value, **rest
in Symbol : key => Symbol : value, **rest
end
β which renders the pin operator ^
(and for those who oppose, their unpin operator(s)) unnecessary: expressions before it are always pinned values, and expressions after it are always case
-in
variable declarations.
good = 8..10
okay = 5..7
skip = 0
case x
in skip : # Syntax sugar for skip : _
# skip
in good : good_value
puts good_value
in okay : okay_value
warn okay_value
else : bad_value # Syntax sugar for BasicObject : bad_value
raise bad_value.to_s
end
The second option still looks like an unpin operator for sugary code, however, if pinning values β
case array
in :, : *all_but_first # Syntax sugar for BasicObject : _, BasicObject : *all_but_first
p all_but_first
end
β are somehow preferred over declaring variables:
case array
in _, *all_but_first # Current implementation
p all_but_first
end
Regarding rescue
¶
We canβt change the =>
part in rescue
, of course; but we donβt need to. Hash
es are not Exception
s anyway.
Updated by ParadoxV5 (π»ππ―ππ‘π¬π΅β
€βΉ β₯) 8 months ago
- Subject changed from Feedback regarding `=>` in βAsβ Pattern Matching to Feedback regarding => in βAsβ Pattern Matching