• Let's decide in which release the chilled string deprecation warning shows up regardless of verbosity level (R1) to make progress on this. How about 4.0?
• Otherwise in 10 years all Ruby files will still have to begin with frozen_string_literal: true to not be a performance trap.

[Bug #21654] Set#new calls extra methods compared to previous versions

• Set#new is calling "size" on its input, this is causing extra database queries in our app
• The bug was introduced in d4020dd5faf28486123853e7f00c36139fc07793 in order to detect Set.new(0..)
• I think we should revert d4020dd5faf28486123853e7f00c36139fc07793 and allow Set.new(0..) to hang

[Feature #20163] Add Integer#popcount

• Matz asked for real-world use cases, and I provided one
• Bit arrays can be used to represent undirected graphs, and "popcount" allows us to count edges

• The main point of the issue is already resolved in both parsers
• END { break } is not a syntax error in any parser
• Any reason not to treat END { break } the same as BEGIN { break } which is invalid?
• Implementation for prism here https://github.com/ruby/prism/pull/3707

• TL;DR linking with ruby.dll overrides some libc symbols on Windows
• The ticket proposes to stop all overrides, is that acceptable?
• If not, removing the override for specifically fclose() seems to practically fix the problem for reports cited in the ticket. How about that?
• If we keep the fclose() override, it's hard or impossible for C99 extensions to access the standardized version of the function.

• There seems to be no straightforward way to trace gvar reads/writes in runtime
• Kernel.trace_var only works when gvar name is known in advance
• global_variables hash does not provide enough granularity
• that would be beneficial for a runtime analysis Ruby tools I'm working on
• it’s unclear whether "special" gvars (like $! or $LOAD_PATH) should be traced

• This method would be useful for finding the last instance of something in a list.
• There is precedence with index/rindex.
• A lot of people are using reverse_each.find, which is not as nice.
• Can I add this method?

• deep_freeze has been proposed and rejected many times over the years
• Ractor.make_shareable is being introduced which primarily freezes objects for sharing across Ractors.
• Deep freezing has much more utility than just Ractors, such as thread-based concurrency.
• Rubyists should not have to call a Ractor method to deep freeze if they won't be using Ractors
• It is time to add a general purpose deep_freeze method