Feature #16960
openFeedback 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 Anonymous over 4 years ago
- Subject changed from Feedback regarding `=>` in ‘As’ Pattern Matching to Feedback regarding => in ‘As’ Pattern Matching