Issue #18080 has been updated by yui-knk (Kaneko Yuichiro).
It's possible
https://github.com/yui-knk/ruby/tree/bugs_18080.
However need to notice about inconsistency for one line pattern matching for command call
without block, like `[].append 1 => a`. Because this is interpreted as `#append` call
with hash (`1 => a`) now, so it's impossible to change the behavior without
introducing incompatibility.
```ruby
[].append => a
[].append in a
[].append do
end => a
[].append do
end in a
[].append(1) => a
[].append(1) in a
[].append(1) do
end => a
[].append(1) do
end in a
# Only this is interpreted as #append method call with hash argument
[].append 1 => a
[].append 1 in a
[].append 1 do
end => a
[].append 1 do
end in a
```
In my opinion (1) is more clear than (2).
(1) Method call without surrounding parameters parenthesis can not be put on left of
single line pattern matching
(2) Almost all method calls can be on left of single line pattern matching but there is
one exception (a) without block (b) without parenthesis for parameters (c) pattern
matching with `=>`
# Note
The inconsistency can be found as Shift/Reduce conflict. In this state, shift derives
`arg_value • "=>" arg_value` (hash), on the other hand reduce derives
`command_call => p_top_expr_body` (pattern matching).
https://github.com/yui-knk/ruby/tree/bugs_18080_2
```
State 223
shift/reduce conflict on token "=>":
308 args: arg_value •
759 assoc: arg_value • "=>" arg_value
First example: $@1 k_return arg_value • "=>" arg_value opt_block_arg
"=>" @7 @8 p_top_expr_body opt_terms "end-of-input"
Shift derivation
$accept
↳ 0: program
"end-of-input"
↳ 2: $@1 top_compstmt
↳ 3: top_stmts
opt_terms
↳ 5: top_stmt
↳ 7: stmt
↳ 37: expr
↳ 65: command
"=>" @7 @8 p_top_expr_body
↳ 97: k_return call_args
↳ 299: assocs
opt_block_arg
↳ 757: assoc
↳ 759:
arg_value • "=>" arg_value
Second example: $@1 k_return arg_value • opt_block_arg "=>" @7 @8
p_top_expr_body opt_terms "end-of-input"
Reduce derivation
$accept
↳ 0: program
"end-of-input"
↳ 2: $@1 top_compstmt
↳ 3: top_stmts
opt_terms
↳ 5: top_stmt
↳ 7: stmt
↳ 37: expr
↳ 65: command_call
"=>" @7 @8 p_top_expr_body
↳ 82: command
↳ 97: k_return call_args
↳ 298: args
opt_block_arg
↳ 308:
arg_value •
```
----------------------------------------
Bug #18080: Syntax error on one-line pattern matching
https://bugs.ruby-lang.org/issues/18080#change-104454
* Author: ko1 (Koichi Sasada)
* Status: Open
* Priority: Normal
* ruby -v: 3.1.0dev
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
One line pattern matching with a method return value with parameters which are not
surrounded by parenthesis raises syntax error.
I think it is not intentional, but nobu said it's hard to support because of parse.y
limitation.
```ruby
p do
end => a
p a #=> nil
p(1) do
end => a
p a #=> 1
p 1 do
end => a
#=>
# syntax error, unexpected =>, expecting end-of-input
# end => a
# ^~
p 1 do
end in a
#=>
# syntax error, unexpected `in', expecting end-of-input
# end in a
# ^~
```
--
https://bugs.ruby-lang.org/