January 2026 - ruby-core - ml.ruby-lang.org

[ruby-core:124548] [Ruby Feature#21821] Add Stack and SizedStack classes
by Eregon (Benoit Daloze) 14 Jan '26

14 Jan '26

Issue #21821 has been updated by Eregon (Benoit Daloze). p8 (Petrik de Heus) wrote in #note-11: > The ConditionVariable in Puma 7's thread pool is causing issues in JRuby: [https://github.com/jruby/jruby/issues/9140](https://github.com/jruby/jruby/… I recall it was also causing issues in TruffleRuby back then hence my short attempt to remove it. But we fixed ConditionVariable since then and it seems to work fine now (though indeed there is the overhead of creating a `InterruptedException`, but the whole Java blocking/interruption is basically based on those so seems hard to fix and more of a JVM bug IMO). `ConditionVariable` are a very useful concurrency primitive, so I don't think it's productive in general to try to avoid them, better to optimize them since they are used in plenty of places. > So I thought about attempting to rewrite it without the ConditionVariable (but that is way out of my expertise and now I'm learning not possible with a SizedQueue). Not possible is probably too strong, what I meant to say is when I looked at it and tried it there are some methods I couldn't implement with a SizedQueue, so the API back then and I think the API now has methods which are not implementable with a SizedQueue. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116119 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124547] [Ruby Feature#13683] Add strict Enumerable#single
by Eregon (Benoit Daloze) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by Eregon (Benoit Daloze). @baweaver FYI your reply didn't work on Redmine, it shows an empty comment by Anonymous, so I'd suggest you add on Redmine for future comments to workaround that. The comment is: > I would advocate for using a `!` on the end of whatever we pick to signify it does something "dangerous" (e.g. exception) just as a warning for users. This is not the case for core methods, core methods only have a `!` if it's a more dangerous version of a non-! method, which is not the case here if we add a single method. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116116 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124546] [Ruby Feature#13683] Add strict Enumerable#single
by Eregon (Benoit Daloze) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by Eregon (Benoit Daloze). I think for the use case of "check if a single value" from @Dan0042 then `ary.first if ary.size == 1` or so is good enough. I agree the new method here is meant to assert and the usefulness of it comes from the exception if it unexpectedly doesn't hold. `value = ary.size == 1 ? ary.first : raise(SomeError)` is of course possible but that's quite verbose and I think a pattern worth capturing as a core method. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116115 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124543] [Ruby Feature#13683] Add strict Enumerable#single
by mame (Yusuke Endoh) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by mame (Yusuke Endoh). `Enumerable#sole` is a method that should only be used when the Enumerable has only one element. Using it in other cases (0 or 2+ elements) is considered a bug, or literally "exceptional", so raising an exception makes perfect sense. In the dev meeting, when we consider the name `Enumerable#one!`, I briefly mentioned `Enumerable#one`, a moderate variant that returns `nil` instead of raising an exception. But no one seriously considered it because we can find no use case for it. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116111 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:124541] [Ruby Feature#13683] Add strict Enumerable#single
by Dan0042 (Daniel DeLorme) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by Dan0042 (Daniel DeLorme). @byroot it depends on the use case. Yes sometimes it's an assertion that should raise an error, but at other times we want to find the single element, and do something **only if** found, not raise an error. @ufuk the same way you disambiguate when #find returns nil. Or #delete or #delete_at or #[] or #bsearch or #first, etc. In other words Ruby is designed so that nil is equivalent to undefined and this is the way it normally works for any method that returns one of the elements of the collection. And as I said I'm not against having both return-nil and raise-error versions, but I do consider that return-nil is the more relevant one. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116109 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124540] [Ruby Feature#13683] Add strict Enumerable#single
by ufuk (Ufuk Kayserilioglu) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by ufuk (Ufuk Kayserilioglu). @Dan0042 If the proposed method isn't going to raise an exception, then how would one disambiguate between a `nil` result because the collection has a single entry which is `nil` and a `nil` result since the collection has (for example) 2 elements? If someone is calling `collection.one` then they would be expecting to find a single element in the collection. Failure of that expectation would be an exceptional case, which needs an exception. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116108 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124539] [Ruby Feature#13683] Add strict Enumerable#single
by jeremyevans0 (Jeremy Evans) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by jeremyevans0 (Jeremy Evans). matz (Yukihiro Matsumoto) wrote in #note-41: > One possible solution is providing our version of `sole` that raises `ArgumentError`, only if AcriveSupport would define `SoleItemExpectedEror = ArgumentError` or something similar. My understanding is that `ArgumentError` should be used for invalid arguments. Since the method doesn't accept arguments, using `ArgumentError` for this feels wrong to me. If we do not want to introduce an exception subclass for this, I think `RangeError` would be better than `ArgumentError`, because the issue is the the size/range of the receiver is not as expected. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116107 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124537] [Ruby Feature#13683] Add strict Enumerable#single
by byroot (Jean Boussier) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by byroot (Jean Boussier). The exception here isn't meant to be used for control flow any more than `KeyError` is when you use `Hash#fetch`. It's used as some sort of assertion, you wouldn't typically rescue it. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116105 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124536] [Ruby Feature#13683] Add strict Enumerable#single
by Dan0042 (Daniel DeLorme) 14 Jan '26

14 Jan '26

Issue #13683 has been updated by Dan0042 (Daniel DeLorme). Please consider a method that returns nil instead of raising an exception. Exceptions should not be used for control flow. Which one is better? ```ruby #method returning nil val = collection.one{ ... } #match or nil val = collection.one{ ... } or raise MyError #match or error #method raising error val = collection.one!{ ... } rescue nil #match or nil val = collection.one!{ ... } #match or error ``` imho returning nil is better; we pay the cost of an exception only when we need it. Of course I'm not against having both. ---------------------------------------- Feature #13683: Add strict Enumerable#single https://bugs.ruby-lang.org/issues/13683#change-116104 * Author: dnagir (Dmytrii Nagirniak) * Status: Feedback ---------------------------------------- ### Summary This is inspired by other languages and frameworks, such as LINQ's [Single](https://msdn.microsoft.com/en-us/library/bb155325%28v=vs.110%29.asp… (pardon MSDN reference), which has very big distinction between `first` and `single` element of a collection. - `first` normally returns the top element, and the developer assumes there could be many; - `single` returns one and only one element, and it is an error if there are none or more than one. We, in Ruby world, very often write `fetch_by('something').first` assuming there's only one element that can be returned there. But in majority of the cases, we really want a `single` element. The problems with using `first` in this case: - developer needs to explicitly double check the result isn't `nil` - in case of corrupted data (more than one item returned), it will never be noticed `Enumerable#single` addresses those problems in a very strong and specific way that may save the world by simply switching from `first` to `single`. ### Other information - we may come with a better internal implementation (than `self.map`) - better name could be used, maybe `only` is better, or a bang version? - re-consider the "block" implementation in favour of a separate method (`single!`, `single_or { 'default' }`) The original implementation is on the ActiveSupport https://github.com/rails/rails/pull/26206 But it was suggested to discuss the possibility of adding it to Ruby which would be amazing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:124535] [Ruby Feature#21821] Add Stack and SizedStack classes
by mame (Yusuke Endoh) 14 Jan '26

14 Jan '26

Issue #21821 has been updated by mame (Yusuke Endoh). Discussed at the dev meeting. No conclusion has been reached, but some opinions raised included: * Instead of introducing separate classes for each algorithm, how about introducing a generic container class under a more use-case-driven name like `Thread::Pool`? `Thread::Pool.new(:fifo)` or `Thread::Pool.new(:lifo)` could determine how to retrieve items, for example. (note: @matz didn't say his opinion about this, as I recall) * If we only need to add a method to retrieve items LIFO from Queue, returning to #21721, how about a method name that is clearly not orthodox, like `Queue#unpush`? @matz said he can compromise if a better name could be found. ---------------------------------------- Feature #21821: Add Stack and SizedStack classes https://bugs.ruby-lang.org/issues/21821#change-116103 * Author: byroot (Jean Boussier) * Status: Open * Target version: 4.1 ---------------------------------------- ### Context `Queue` and `SizedQueue` are very useful and performant constructs, however they only allow for FIFO queues. Some use cases do call for LIFO queues AKA stacks. For instance, in the case of connection pool, it's often preferable to use a stack. ### Feature I'd like to introduce `Stack` and `SizedStack` classes, to mirror `Queue` and `SizedQueue`. They'd have exactly the same method and behavior at the exception of dequeuing order. ### Thread namespace? Currently `Queue` and `SizedQueue` are technically defined under `Thread` and aliased in `Object`. I wonder if that's something we should do for `Stack` too, or just some historical thing we shouldn't perpetuate. -- https://bugs.ruby-lang.org/

1 0