## Feature #18242

open### Parser makes multiple assignment sad in confusing way

**Description**

Example:

```
a, b = 2, 1 if 1 < 2 # Works
a, b = [2, 1] if 1 < 2 # Works
(a, b) = 2, 1 if 1 < 2 # Works
(a, b) = [2, 1] if 1 < 2 # Works
(a, b = [2, 1]) if 1 < 2 # Works
a, b = 2, 1 unless 2 < 1 # Works
a, b = [2, 1] unless 2 < 1 # Works
(a, b) = 2, 1 unless 2 < 1 # Works
(a, b) = [2, 1] unless 2 < 1 # Works
(a, b = [2, 1]) unless 2 < 1 # Works
1 < 2 and a, b = 2, 1 # SyntaxError
1 < 2 and a, b = [2, 1] # SyntaxError
1 < 2 and (a, b) = 2, 1 # SyntaxError
1 < 2 and (a, b) = [2, 1] # SyntaxError
(1 < 2) and a, b = 2, 1 # SyntaxError
(1 < 2) and a, b = [2, 1] # SyntaxError
(1 < 2) and (a, b) = 2, 1 # SyntaxError
(1 < 2) and (a, b) = [2, 1] # SyntaxError
1 < 2 and (a, b = 2, 1) # Works
1 < 2 and (a, b = [2, 1]) # Works
2 < 1 or a, b = 2, 1 # SyntaxError
2 < 1 or a, b = [2, 1] # SyntaxError
2 < 1 or (a, b) = 2, 1 # SyntaxError
2 < 1 or (a, b) = [2, 1] # SyntaxError
(2 < 1) or a, b = 2, 1 # SyntaxError
(2 < 1) or a, b = [2, 1] # SyntaxError
(2 < 1) or (a, b) = 2, 1 # SyntaxError
(2 < 1) or (a, b) = [2, 1] # SyntaxError
2 < 1 or (a, b = 2, 1) # Works
2 < 1 or (a, b = [2, 1]) # Works
```

Based on the precedence rules I've been able to find, all of these should work.

Believe it or not, there are cases where using `and`

or `or`

in a stanza of lines is much more readable.

Should the parser allow all of these? See attached driver script to reproduce this output.

**Files**

#### Updated by jeremyevans0 (Jeremy Evans) 7 months ago

**Backport**deleted ()*2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN***ruby -v**deleted ()*ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]***Tracker**changed from*Bug*to*Feature***File**and-or-masgn-18242.diff and-or-masgn-18242.diff added

The parser is currently not setup to handle this, so I don't think it is a bug. You would have to add new parser rules to allow it, so I would consider this a feature request and not a bug. Attached is a patch that implements the necessary parser rules, without causing any conflicts. However, the patch doesn't include the parts needed to make ripper work, as I couldn't figure that out. @nobu (Nobuyoshi Nakada), any chance you could add the necessary code to make ripper work?

#### Updated by danh337 (Dan H) 7 months ago

jeremyevans0 (Jeremy Evans) wrote in #note-1:

[...] Attached is a patch that implements the necessary parser rules, without causing any conflicts. However, the patch doesn't include the parts needed to make ripper work, as I couldn't figure that out. @nobu (Nobuyoshi Nakada), any chance you could add the necessary code to make ripper work?

@jeremyevans0 (Jeremy Evans) you rock. Thanks sir.

#### Updated by nobu (Nobuyoshi Nakada) 7 months ago

That patch seems not including `1 < 2 and a = 1, 2`

.

#### Updated by danh337 (Dan H) 7 months ago

nobu (Nobuyoshi Nakada) wrote in #note-3:

That patch seems not including

`1 < 2 and a = 1, 2`

.

Thank you @nobu (Nobuyoshi Nakada) !

#### Updated by danh337 (Dan H) 7 months ago

@nobu (Nobuyoshi Nakada) I built your PR branch and confirmed that this new parsing works great with the `driver.rb`

attached.

Will this patch have to wait for the 3.1.0 release? Sorry I'm not sure how the whole patching and backporting processes work. (But I'm pretty sure it can get complicated.) If these were syntax errors in the past, should the patch be safe for stable versions too?

#### Updated by danh337 (Dan H) 7 months ago

Attached is an improved driver. Again, every test case works with nobu's branch.

#### Updated by nobu (Nobuyoshi Nakada) 7 months ago

I agree with @jeremyevans0 (Jeremy Evans) on that this is not a bug.

Feature requests need the approval by Matz to merge.