ruby-core

Mailing list archive

[#114936] [Ruby master Feature#19908] Update to Unicode 15.1 — "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>

Issue #19908 has been reported by nobu (Nobuyoshi Nakada).

24 messages 2023/10/02

[#115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19921 has been reported by vo.x (Vit Ondruch).

21 messages 2023/10/12

[#115033] [Ruby master Misc#19925] DevMeeting-2023-11-07 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #19925 has been reported by mame (Yusuke Endoh).

12 messages 2023/10/13

[#115068] [Ruby master Bug#19929] Warnings for `mutex_m`, `drb` and `base64` appears while the gem spec has explicit dependencies — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

Issue #19929 has been reported by yahonda (Yasuo Honda).

8 messages 2023/10/17

[#115071] [Ruby master Misc#19931] to_int is not for implicit conversion? — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19931 has been reported by Dan0042 (Daniel DeLorme).

16 messages 2023/10/17

[#115139] [Ruby master Bug#19969] Regression of memory usage with Ruby 3.1 — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>

Issue #19969 has been reported by hsbt (Hiroshi SHIBATA).

8 messages 2023/10/24

[#115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19972 has been reported by vo.x (Vit Ondruch).

11 messages 2023/10/25

[#115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil` — "ufuk (Ufuk Kayserilioglu) via ruby-core" <ruby-core@...>

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu).

21 messages 2023/10/29

[ruby-core:115001] [Ruby master Bug#19918] Should `a[&b]=c` be syntax valid?

From: "Eregon (Benoit Daloze) via ruby-core" <ruby-core@...>
Date: 2023-10-11 08:50:42 UTC
List: ruby-core #115001
Issue #19918 has been updated by Eregon (Benoit Daloze).


mame (Yusuke Endoh) wrote in #note-1:
> Assuming this is intentionally valid, I wonder if `a[&b] = c` should evaluate `b` before `c`.

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/test/ruby/test_parse.rb#L502




-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [email protected]
 To unsubscribe send an email to [email protected]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread