Issue #19918 has been updated by mame (Yusuke Endoh). Assuming this is intentionally valid, I wonder if `a[&b] = c` should evaluate `b` before `c`. ---------------------------------------- Bug #19918: Should `a[&b]=c` be syntax valid? https://bugs.ruby-lang.org/issues/19918#change-104866 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-11T04:46:58Z master 40ab7b8c24) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These codes are syntax valid now. Prism parses it as syntax error. ~~~ruby a[&b]=c a[&b]+=c a[&b]&&=c a[&b]||=c ~~~ Is this syntax intentional or should be error? Issue of Prism https://github.com/ruby/prism/issues/1636 It's added in test_parse.rb https://github.com/ruby/ruby/blob/40ab7b8c244de20007cb45846f41de3a01f7ea0c/… -- https://bugs.ruby-lang.org/

Issue #19918 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-1: That's the kind of complications which I think illustrates the Ruby syntax shouldn't support such edge cases. It does not seem nearly useful or used enough to warrant those complications. Literally I have never seen any code using `[]=` with a block. If a block is useful the method should not be named with `[]=` but something clearer so it's easy to pass a block without such contortions. ---------------------------------------- Bug #19918: Should `a[&b]=c` be syntax valid? https://bugs.ruby-lang.org/issues/19918#change-104869 * Author: tompng (tomoya ishida) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-10-11T04:46:58Z master 40ab7b8c24) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These codes are syntax valid now. Prism parses it as syntax error. ~~~ruby a[&b]=c a[&b]+=c a[&b]&&=c a[&b]||=c ~~~ Is this syntax intentional or should be error? Issue of Prism https://github.com/ruby/prism/issues/1636 It's added in test_parse.rb https://github.com/ruby/ruby/blob/40ab7b8c244de20007cb45846f41de3a01f7ea0c/… -- https://bugs.ruby-lang.org/

Issue #19918 has been updated by mame (Yusuke Endoh). Status changed from Open to Assigned Assignee set to yui-knk (Kaneko Yuichiro) Discussed at the dev meeting. @matz wanted to allow `a[&b]` and forbid `a[&b] = c` if the implementation is not overly cumbersome. @yui-knk What do you think? Note: During the meeting, we found that the compilation of `a[&b], c[&d] = e, f` is apparently buggy. If it is difficult to prohibit the grammar, we need to fix this bug. ---------------------------------------- Bug #19918: Should `a[&b]=c` be syntax valid? https://bugs.ruby-lang.org/issues/19918#change-106338 * Author: tompng (tomoya ishida) * Status: Assigned * Priority: Normal * Assignee: yui-knk (Kaneko Yuichiro) * ruby -v: ruby 3.3.0dev (2023-10-11T04:46:58Z master 40ab7b8c24) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- These codes are syntax valid now. Prism parses it as syntax error. ~~~ruby a[&b]=c a[&b]+=c a[&b]&&=c a[&b]||=c ~~~ Is this syntax intentional or should be error? Issue of Prism https://github.com/ruby/prism/issues/1636 It's added in test_parse.rb https://github.com/ruby/ruby/blob/40ab7b8c244de20007cb45846f41de3a01f7ea0c/… -- https://bugs.ruby-lang.org/