Feedback regarding => in ‘As’ Pattern Matching
The only obstacle preventing the use of non-symbol keys in hash patterns is simply the fact that
=> is used for both
Hashes 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
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
We can’t change the
=> part in
rescue, of course; but we don’t need to.
Hashes are not