Feature #16960: Feedback regarding => in ‘As’ Pattern Matching

• Status: Open
• Assignee: -
• Target version: -

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 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. Hashes are not Exceptions anyway.

• Subject changed from Feedback regarding `=>` in ‘As’ Pattern Matching to Feedback regarding => in ‘As’ Pattern Matching