October 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:119587] [Ruby master Bug#20809] Ripper fails to parse/tokenize nested heredocs within embexpr
by tompng (tomoya ishida) 22 Oct '24

22 Oct '24

Issue #20809 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20809: Ripper fails to parse/tokenize nested heredocs within embexpr https://bugs.ruby-lang.org/issues/20809 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-22T09:04:30Z master 54065f3b7b) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In this example, Ripper wrongly concats `"s333\n"` and `"s4444"`. ~~~ruby require 'ripper' code1 = '<<HEREDOC1 s1 #{<<HEREDOC2}s333 s22 HEREDOC2 s4444#{55555} HEREDOC1' p Ripper.tokenize(code1) # => ["<<HEREDOC1", "\n", "s1\n", "\#{", "<<HEREDOC2", "}", "s333\ns4444", "s22\n", "HEREDOC2\n", "\#{", "55555", "}", "\n", "HEREDOC1"] ~~~ In this example, result of `Ripper.sexp` is wrong. `"s333"` disappears. ~~~ruby code2 = '<<HEREDOC1 s1 #{<<HEREDOC2}s333 s22 HEREDOC2 s4444 HEREDOC1' p eval(code2) # => "s1\ns22\ns333\ns4444\n" p Ripper.sexp(code2) # => [:program, [[:string_literal, [:string_content, [:@tstring_content, "s1\n", [2, 0]], [:string_embexpr, [[:string_literal, [:string_content, [:@tstring_content, "s22\n", [4, 0]]]]]], [:@tstring_content, "s4444\n", [6, 0]]]]]] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118932] [Ruby master Bug#20693] Dir.tmpdir should perform a real access check before warning about writability
by kjtsanaktsidis (KJ Tsanaktsidis) 22 Oct '24

22 Oct '24

Issue #20693 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20693: Dir.tmpdir should perform a real access check before warning about writability https://bugs.ruby-lang.org/issues/20693 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The code in `Dir.tmpdir` attempts to warn the user if their temp directory is deficient for some reason: ```ruby case when !stat.directory? warn "#{name} is not a directory: #{dir}" when !stat.writable? warn "#{name} is not writable: #{dir}" when stat.world_writable? && !stat.sticky? warn "#{name} is world-writable: #{dir}" else break dir end ``` This check for writability is looking at the user/group/world access bits on the stat output, and determining if the user running Ruby is allowed to write to the temp directory based on that. However, modern operating systems contain other mechanisms apart from the user/group/world bits which can grant access to a directory that would otherwise be denied, or vice versa. Things like: * Posix ACL's * Linux's capabilities like CAP_DAC_OVERRIDE * Linux Security Modules like SELinux or AppArmor * Syscall filters like Linux's seccomp * Granular capability systems like FreeBSD's Capsicum * OpenBSD's pledge and unveil * Windows too has a rich ACL system for controlling filesystem access To address this, we should call `File.writable?` instead of `stat.writable?`, which asks the system whether the file is writable using the `euidaccess()` function if available. On Linux/glibc, at least, this will issue an `access(2)` syscall, and the Kernel can take all of the above into account. n.b. if Ruby is running as suid, then glibc currently will NOT ask the kernel to perform the access check in `euidaccess()`, and instead does a similar thing to what `Stat#writable?` does (https://github.com/bminor/glibc/blob/7f04bb4e49413bd57ac3215f3480b09ae71319…) This is because of the relatively new `faccessat2(2)` syscall is required to do this properly, and there is some ecosystem issues with leveraging this by default (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1900021) Since running Ruby as suid is probably a very bad idea anyway, and the glibc implementation isn't any worse than the `Stat#writable?` one, this seems OK though. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:119585] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by zverok (Victor Shepelev) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by zverok (Victor Shepelev). I believe that the general agreement is that short `to_{t}` methods (`to_s`, `to_i`, `to_h`, `to_a`) have a semantics of “have some {type} representation/can be converted to {type}", while long `to_{type}` ones have a meaning of “are kind-of {type}”. Mostly (though not exclusively), `to_{t}` is used via explicit calls, while `to_{type}` converts the object implicitly on various operators. Now, I believe that using `to_h` (an explicit conversion method) implicitly on `**` would lead to a lot of unintended consequences. Things that typically have `to_h` but are not intended as “option hashes” are, for example: * every Enumerable * most of model-like things (from ActiveRecord to mere Struct) Having them suddenly unpack when nobody intended that (say, typoing `**array` instead of `*array`; or by mistake passing model instance instead of some `options` to a place where it would be handled with `**options`) might lead to very confusing error messages at the very least, and mysterious, hard to debug behavior in worse cases. PS: I actually believe that `*` invoking `to_a` and not `to_ary` brings more bad than good (things like `Time` or `Struct` can be unpacked when, again, nobody has intended it; it also breaks the mental model of explicit/implicit conversion methods). However, it is obviously too late to fix that. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110204 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119581] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by sanjioh (Fabio Sangiovanni) 21 Oct '24

21 Oct '24

Issue #15381 has been updated by sanjioh (Fabio Sangiovanni). Eregon (Benoit Daloze) wrote in #note-4: > Should `**` call `to_h` rather than `to_hash`, similar to `*` calling `to_a` and not `to_ary`? Hi, I’m learning Ruby and the fact that `**` calls `to_hash` rather than `to_h` surprised me; I would expect it to be consistent to `*` calling `to_a`. I suppose that changing this behavior would break to much code, though. A pointer to the decision making process that lead to using `to_hash` would be helpful nonetheless. Thanks! ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110200 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119561] [Ruby master Misc#20806] Redmine ML forwarding seems to be broken (likely since Oct 15)
by vo.x (Vit Ondruch) 21 Oct '24

21 Oct '24

Issue #20806 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Misc #20806: Redmine ML forwarding seems to be broken (likely since Oct 15) https://bugs.ruby-lang.org/issues/20806 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- I am subscribed to ruby-core ML and it seems that Redmine have not forwarded any notification there since ~Oct 15. Could somebody PTAL? -- https://bugs.ruby-lang.org/

2 3

[ruby-core:119556] [Ruby master Bug#20804] Stop reserving stack ahead-of-time in on Linux
by kjtsanaktsidis (KJ Tsanaktsidis) 21 Oct '24

21 Oct '24

Issue #20804 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20804: Stop reserving stack ahead-of-time in on Linux https://bugs.ruby-lang.org/issues/20804 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In Linux, the main thread generally only gets a small stack mapped in initially. As the application attempts to use more stack memory, the kernel will map in more stack pages. In https://github.com/ruby/ruby/pull/822, we added some logic to force the kernel to eagerly map and fault in the entire stack by writing a fake array near the bottom. This was done in order to fix some cases where heap memory was unexpectedly being allocated in locations close to the stack, which then prevented the stack from growing. I ran into this because this logic needed to be fixed for ASAN (https://github.com/ruby/ruby/pull/11921) However, I actually think we should delete `reserve_stack` entirely, which is the point of this issue. Myself and @rianmcguire had a look at this today and we believe that the original problem was in fact a symptom of a kernel bug. The kernel bug (or at least, what we _think_ was the relevant bug) was fixed in 2017 (https://github.com/torvalds/linux/commit/c204d21f2232d875e36b8774c36ffd027d…) On my machine today, under ruby 3.3.2 (2024-05-30 revision e5a195edf6) and kernel 6.10.12-200.fc40.x86_64 I can no longer reproduce the problem demonstrated by the repro script (https://gist.github.com/csfrancis/46e360d401609275246c) ``` kjtsanaktsidis@kjtsanaktsidis-laptop ~ % ./repro.rb new minimum diff: 140730206072832 (2) new minimum diff: 140725853872128 (4) new minimum diff: 140723732975616 (10) new minimum diff: 140719631585280 (14) new minimum diff: 140719552581632 (69) new minimum diff: 140719410409472 (159) new minimum diff: 140719327940608 (1191) new minimum diff: 140719326601216 (3111) new minimum diff: 140719312199680 (6098) ``` Performing this kind of stack reservation actually causes _other_ problems - if RLIMIT_STACK is set to a high value, performing the eager mapping like this can fail for lack of real memory ``` kjtsanaktsidis@kjtsanaktsidis-laptop ~ % ulimit -s 1000000000 kjtsanaktsidis@kjtsanaktsidis-laptop ~ % ruby -e "puts 'hi'" zsh: segmentation fault (core dumped) ruby -e "puts 'hi'" ``` So, therefore, I believe the right thing to do is to just delete `reserve_stack`. Are there any objections to doing this? -- https://bugs.ruby-lang.org/

2 2

[ruby-core:112058] [Ruby master Bug#19383] Time.now.zone encoding for German display language in Windows is incorrect
by stringsn88keys (Thomas Powell) 21 Oct '24

21 Oct '24

Issue #19383 has been reported by stringsn88keys (Thomas Powell). ---------------------------------------- Bug #19383: Time.now.zone encoding for German display language in Windows is incorrect https://bugs.ruby-lang.org/issues/19383 * Author: stringsn88keys (Thomas Powell) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- OS: Verified on Windows 10 and Windows Server 2022 and Ruby 2.7.7 through 3.1.3 Display language: Verified on German, but may impact other languages in which Time.now.zone returns characters that aren't [A-Za-z]. Time zone: CET (UTC +01:00) Amsterdam, Berlin, ... Time.now.zone # => "Mitteleuro\xE3ische Zeit" Time.now.zone.encoding # => #<Encoding:IBM437> puts Time.now.zone # => "Mitteleurop∑ische Zeit" (should be "Mitteleuropäische Zeit") Time.now.zone.encode(Encoding::UTF_8) # => "Mitteleurop∑ische Zeit" Doing a force_encoding on all encodings in Encoding.list reveals that ISO-8859-(1..16) and Windows-125(0,2,4,7) work to coerce the ä out of the time zone string: Time.now.zone.force_encoding(Encoding::WINDOWS_1252) # => "Mitteleuro\xE3ische Zeit" ... but ... Time.now.zone.force_encoding(Encoding::WINDOWS_1252).encode(Encoding::UTF_8) #=> "Mitteleuropäische Zeit" Related issue: This improper encoding/rendering caused Ohai's JSON output to be unparseable. Workaround was forcing to Windows-1252. https://github.com/chef/ohai/pull/1781 -- https://bugs.ruby-lang.org/

5 10

[ruby-core:117957] [Ruby master Bug#20500] Non-system directories are not searched when checking for jemalloc headers and libs, and building `enc`
by lish82 (Hiroki Katagiri) 21 Oct '24

21 Oct '24

Issue #20500 has been reported by lish82 (Hiroki Katagiri). ---------------------------------------- Bug #20500: Non-system directories are not searched when checking for jemalloc headers and libs, and building `enc` https://bugs.ruby-lang.org/issues/20500 * Author: lish82 (Hiroki Katagiri) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found a problem similar to #20494 on jemalloc It's similar to #20494, but it has a few more issues Problems: - Non-system directories (specified by `--with-opt-dir`) are not searched when checking jemalloc headers (almost the same as #20494) - Non-system directories are not searched when checking jemalloc libs - Non-system directories are not searched when building the `enc` directory sources I have confirmed that this problem can be fixed by applying the following patch: ```patch diff --git a/configure.ac b/configure.ac index 169662c..b2dce70 100644 --- a/configure.ac +++ b/configure.ac @@ -1392,6 +1392,8 @@ AC_ARG_WITH([jemalloc], [with_jemalloc=$withval], [with_jemalloc=no]) AS_IF([test "x$with_jemalloc" != xno],[ # find jemalloc header first + save_CPPFLAGS="${CPPFLAGS}" + CPPFLAGS="${INCFLAGS} ${CPPFLAGS}" malloc_header= AC_CHECK_HEADER(jemalloc/jemalloc.h, [malloc_header=jemalloc/jemalloc.h], [ AC_CHECK_HEADER(jemalloc.h, [malloc_header=jemalloc.h]) @@ -1423,6 +1425,8 @@ AS_IF([test "x$with_jemalloc" != xno],[ done done ]) + CPPFLAGS="${save_CPPFLAGS}" + unset save_CPPFLAGS with_jemalloc=${rb_cv_jemalloc_library} AS_CASE(["$with_jemalloc"], [no], diff --git a/enc/Makefile.in b/enc/Makefile.in index 6920bc9..ce93fdd 100644 --- a/enc/Makefile.in +++ b/enc/Makefile.in @@ -52,7 +52,7 @@ optflags = @optflags@ debugflags = @debugflags@ warnflags = @warnflags@ CCDLFLAGS = @CCDLFLAGS@ -INCFLAGS = -I. -I$(arch_hdrdir) -I$(hdrdir) -I$(top_srcdir) +INCFLAGS = -I. -I$(arch_hdrdir) -I$(hdrdir) -I$(top_srcdir) @incflags@ DEFS = @DEFS@ CPPFLAGS = @CPPFLAGS@ -DONIG_ENC_REGISTER=rb_enc_register LDFLAGS = @LDFLAGS@ ``` --- On a side note, I think there might be other parts affected by the changes bellow: https://github.com/ruby/ruby/pull/8449 I thought it might be a good idea to review everything thoroughly -- https://bugs.ruby-lang.org/

5 11

[ruby-core:117003] [Ruby master Bug#20314] Simultaneous Timeout expires may raise an exception after the block
by mame (Yusuke Endoh) 21 Oct '24

21 Oct '24

Issue #20314 has been reported by mame (Yusuke Endoh). ---------------------------------------- Bug #20314: Simultaneous Timeout expires may raise an exception after the block https://bugs.ruby-lang.org/issues/20314 * Author: mame (Yusuke Endoh) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Launchable reports `TestTimeout#test_nested_timeout` as a flaky test, and I reproduced it as follows. ```ruby require "timeout" class A < Exception end class B < Exception end begin Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do nil while true end end rescue A, B p $! #=> #<A: execution expired> # Exception B is raised after the above call returns #=> test.rb:16:in `p': execution expired (B) p :end # not reach end ``` This is because the timer thread performs two consecutive `Thread#raise` to the target thread. I have discussed this with @ko1 and have come up with three solutions. ### Solution 1 When multiple nested Timeouts expire simultaneously, raise an exception for the outer-most Timeout and let the inner Timeouts expire without throwing an exception. In the above example, it would only raise A. The problem with this approach is that if you are rescuing A in the inner block, it may never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue A sleep # The exception A is caught. The inner Timeout is already expired, so the code (may) never end. end end end ``` Note that, if A and B did not occur at the same time, it would raise B. This is a race condition. ### Solution 2 When multiple nested Timeouts expire simultaneously, raise an exception for the inner-most Timeout and let the outer Timeouts wait until the inner-most Timeout returns. In the above example, it would raise either A or B, not both. The problem with this approach is that if you are rescuing B in the inner block, it never ends: ```ruby Timeout.timeout(0.1, A) do Timeout.timeout(0.1, B) do begin sleep rescue B sleep # The outer Timeout waits for the inner timeout, and the inner Timeout never return. So this code never ends. end end end ``` ### Solution 3 Make thread interrupt queue one length. If the target thread has already been `Thread#raise(A)`, the new `Thread#raise(B)` blocks until the target thread processes A. Since there will be no more simultaneous Thread#raise, there will be no more exceptions after the end of the block. The timeout timer thread should be changed in consideration that `Thread#raise` may block. -- https://bugs.ruby-lang.org/

3 4

[ruby-core:119551] [Ruby master Feature#16986] Anonymous Struct literal
by danh337 (Dan H) 21 Oct '24

21 Oct '24

Issue #16986 has been updated by danh337 (Dan H). Eregon (Benoit Daloze) wrote in #note-69: > That's pretty slow and inefficient as it creates a new Struct subclass for every Hash it's applied to. > The core idea of this proposal is to make it syntax and disallow **h to make sure that doesn't happen. Um ok so I'm voting against a new syntax. It's not necessary. A simple method like the one above is pretty good evidence. Whatever javascript is doing is not evidence for Ruby. When you say "slow and inefficient" you must be comparing to something else but it isn't clear what you're thinking. If you're comparing to a new notation which does not handle recursive nesting of Struct objects, then of course you're right. But then that notation would be even easier to obviate with a simple method. And then if a new syntax did handle nested Struct objects, then, um there are new Struct objects? Shrug. > This example could be a decent use case for OpenStruct, but that would need to be fixed perf-wise first, which is hard because of compatibility concerns: https://github.com/ruby/ostruct/issues/51 > Wrapping it in your own OpenStruct-like wrapper would likely be the best for now. Sorry I don't understand "best for now". This example is a way to AVOID OpenStruct. The nice things about Struct are (a) it catches typos, and (b) it's way faster than OpenStruct. I don't want smart Ruby folks like @Eregon to spend a lot of time on this. I just wanted to show that a new syntax is not really needed. ---------------------------------------- Feature #16986: Anonymous Struct literal https://bugs.ruby-lang.org/issues/16986#change-110165 * Author: ko1 (Koichi Sasada) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- # Abstract How about introducing anonymous Struct literal such as `${a: 1, b: 2}`? It is almost the same as `Struct.new(:a, :b).new(1, 2)`. # Proposal ## Background In many cases, people use hash objects to represent a set of values such as `person = {name: "ko1", country: 'Japan'}` and access its values through `person[:name]` and so on. It is not easy to write (three characters `[:]`!), and it easily introduces misspelling (`person[:nama]` doesn't raise an error). If we make a `Struct` object by doing `Person = Struct.new(:name, :age)` and `person = Person.new('ko1', 'Japan')`, we can access its values through `person.name` naturally. However, it costs coding. And in some cases, we don't want to name the class (such as `Person`). Using `OpenStruct` (`person = OpenStruct.new(name: "ko1", country: "Japan")`), we can access it through `person.name`, but we can extend the fields unintentionally, and the performance is not good. Of course, we can define a class `Person` with attr_readers. But it takes several lines. To summarize the needs: * Easy to write * Doesn't require declaring the class * Accessible through `person.name` format * Limited fields * Better performance ## Idea Introduce new literal syntax for an anonymous Struct such as: `${ a: 1, b: 2 }`. Similar to Hash syntax (with labels), but with `$` prefix to distinguish. Anonymous structs which have the same member in the same order share their class. ```ruby s1 = ${a: 1, b: 2, c: 3} s2 = ${a: 1, b: 2, c: 3} assert s1 == s2 s3 = ${a: 1, c: 3, b: 2} s4 = ${d: 4} assert_equal false, s1 == s3 assert_equal false, s1 == s4 ``` ## Note Unlike Hash literal syntax, this proposal only allows `label: expr` notation. No `${**h}` syntax. This is because if we allow to splat a Hash, it can be a vulnerability by splatting outer-input Hash. Thanks to this spec, we can specify anonymous Struct classes at compile time. We don't need to find or create Struct classes at runtime. ## Implementatation https://github.com/ruby/ruby/pull/3259 # Discussion ## Notation Matz said he thought about `{|a: 1, b: 2 |}` syntax. ## Performance Surprisingly, Hash is fast and Struct is slow. ```ruby Benchmark.driver do |r| r.prelude <<~PRELUDE st = Struct.new(:a, :b).new(1, 2) hs = {a: 1, b: 2} class C attr_reader :a, :b def initialize() = (@a = 1; @b = 2) end ob = C.new PRELUDE r.report "ob.a" r.report "hs[:a]" r.report "st.a" end __END__ Warming up -------------------------------------- ob.a 38.100M i/s - 38.142M times in 1.001101s (26.25ns/i, 76clocks/i) hs[:a] 37.845M i/s - 38.037M times in 1.005051s (26.42ns/i, 76clocks/i) st.a 33.348M i/s - 33.612M times in 1.007904s (29.99ns/i, 87clocks/i) Calculating ------------------------------------- ob.a 87.917M i/s - 114.300M times in 1.300085s (11.37ns/i, 33clocks/i) hs[:a] 85.504M i/s - 113.536M times in 1.327850s (11.70ns/i, 33clocks/i) st.a 61.337M i/s - 100.045M times in 1.631064s (16.30ns/i, 47clocks/i) Comparison: ob.a: 87917391.4 i/s hs[:a]: 85503703.6 i/s - 1.03x slower st.a: 61337463.3 i/s - 1.43x slower ``` I believe we can speed up `Struct` similarly to ivar accesses, so we can improve the performance. BTW, OpenStruct (os.a) is slow. ``` Comparison: hs[:a]: 92835317.7 i/s ob.a: 85865849.5 i/s - 1.08x slower st.a: 53480417.5 i/s - 1.74x slower os.a: 12541267.7 i/s - 7.40x slower ``` For memory consumption, `Struct` is more lightweight because we don't need to keep the key names. ## Naming If we name an anonymous class, literals with the same members share the name. ```ruby s1 = ${a:1} s2 = ${a:2} p [s1, s2] #=> [#<struct a=1>, #<struct a=2>] A = s1.class p [s1, s2] #=> [#<struct A a=1>, #<struct A a=2>] ``` Maybe that is not a good behavior. -- https://bugs.ruby-lang.org/

1 0