- ruby-core - ml.ruby-lang.org

[ruby-core:111842] [Ruby master Feature#19347] Add Dir.fchdir
by jeremyevans0 (Jeremy Evans) 10 Feb '23

10 Feb '23

Issue #19347 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #19347: Add Dir.fchdir https://bugs.ruby-lang.org/issues/19347 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- Recently, I was working on a program that passes file descriptors over UNIX sockets (using `send_io`/`recv_io`). For file/socket/device descriptors, this works fine using `File#reopen`. However, I found that while Ruby supports `Dir#fileno` to return a directory file descriptor, it cannot use that file descriptor when changing directories. I worked around this in my program by writing the directory path over the UNIX socket, but this results in a TOCTOU vulnerability in certain cases. Passing the directory file descriptor would be simpler and avoid the vulnerability. I've submitted a pull request to implement this method: https://github.com/ruby/ruby/pull/7135 -- https://bugs.ruby-lang.org/

4 8

[ruby-core:112097] [Ruby master Feature#19388] Deprecate SecurityError
by jeremyevans0 (Jeremy Evans) 09 Feb '23

09 Feb '23

Issue #19388 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #19388: Deprecate SecurityError https://bugs.ruby-lang.org/issues/19388 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I think we should deprecate `SecurityError` in Ruby 3.3 and remove it in Ruby 3.4. I think we probably should have deprecated `SecurityError` when `$SAFE` was deprecated, but better late than never. I've submitted a pull request to deprecate it: https://github.com/ruby/ruby/pull/7193 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:112299] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by zverok (Victor Shepelev) 09 Feb '23

09 Feb '23

Issue #18368 has been updated by zverok (Victor Shepelev). Thanks @matz I'll be working on the implementation. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-101734 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112297] [Ruby master Feature#19061] Proposal: make a concept of "consuming enumerator" explicit
by zverok (Victor Shepelev) 09 Feb '23

09 Feb '23

Issue #19061 has been updated by zverok (Victor Shepelev). @matz Thanks for your answer. I'll gather more evidence/real-life examples and will adjust the proposal. My main concern though was not as much some particular usage but general awareness of the difference between the two types of enumerators. The latest evidence of the fact that it is a problem is bug #19294 in the new feature of Ruby 3.2, where even the core team member implementing new functionality hasn't considered that some enumerators would be "consumed" by the first iteration. I believe it to be a pretty important distinction frequently leading to idiosyncrasies and not just a random feature request. But I need to think about how to communicate my intentions and proposals better. ---------------------------------------- Feature #19061: Proposal: make a concept of "consuming enumerator" explicit https://bugs.ruby-lang.org/issues/19061#change-101732 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- **The problem** Let's imagine this synthetic data: ```ruby lines = [ "--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators", "", "Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..." ] ``` The logic of parsing it is more or less clear: * skip the first line * take lines until meet empty, to read the header * take the rest of the lines to read the body It can be easily translated into Ruby code, almost literally: ```ruby def parse(enumerator) puts "Testing: #{enumerator.inspect}" enumerator.next p enumerator.take_while { !_1.empty? } p enumerator.to_a end ``` Now, let's try this code with two different enumerators on those lines: ```ruby require 'stringio' enumerator1 = lines.each enumerator2 = StringIO.new(lines.join("\n")).each_line(chomp: true) puts "Array#each" parse(enumerator1) puts puts "StringIO#each_line" parse(enumerator2) ``` Output (as you probably already guessed): ``` Array#each Testing: #<Enumerator: [...]:each> ["--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators", "", "Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] StringIO#each_line Testing: #<Enumerator: #<StringIO:0x00005581018c50a0>:each_line(chomp: true)> ["From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] ``` Only the second enumerator behaves the way we wanted it to. Things to notice here: 1. Both enumerators are of the same class, "just enumerator," but they behave differently: one of them is **consuming** data on each iteration method, the other does not; but there is no programmatic way to tell whether some enumerator instance is consuming 2. There is no easy way to **make a non-consuming enumerator behave in a consuming way**, to open a possibility of a sequence of processing "skip this, take that, take the rest" **Concrete proposal** 1. Introduce an `Enumerator#consuming?` method that will allow telling one of the other (and make core enumerators like `#each_line` properly report they are consuming). 2. Introduce `consuming: true` parameter for `Enumerator.new` so it would be easy for user's code to specify the flag 3. Introduce `Enumerator#consuming` method to produce a consuming enumerator from a non-consuming one: ```ruby # reference implementation is trivial: class Enumerator def consuming source = self Enumerator.new { |y| loop { y << source.next } } end end enumerator3 = lines.each.consuming parse(enumerator3) ``` Output: ``` ["From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112287] [Ruby master Bug#19425] Merge the internal only "private" GC headers together
by eightbitraptor (Matthew Valentine-House) 09 Feb '23

09 Feb '23

Issue #19425 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #19425: Merge the internal only "private" GC headers together https://bugs.ruby-lang.org/issues/19425 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Github PR: [7273](https://github.com/ruby/ruby/pull/7273) Currently we have 4 headers named `gc.h` * `gc.h` * `internal/gc.h` * `include/ruby/internal/gc.h` * `include/ruby/internal/intern/gc.h` The first two are private and internal to the CRuby codebase, the latter 2 are visible to C extensions. [This PR](https://github.com/ruby/ruby/pull/7273) attempts to merge the two internal headers `gc.h` and internal/gc.h` into a single header `internal/gc.h` in order to simplify the codebase and put all the gc related interface in a single place. Here is the history of the 2 internal only `gc.h` headers as I've been able to understand from the commit logs: * `gc.h` was created as part of the YARV merge in 2006, it contained only some `defines` for debug related macros. * In 2010 some function declarations were added to it to expose some functionality (`rb_objspace_each_objects`) to the `objspace` extension * In May 2011 `internal.h` was created as a place to put shared, but internal only declarations. * In June 2011 GC related functions started being committed to `internal.h` * In 2019 `internal.h` was refactored and `internal/gc.h` was created As of 2023 internally used code continues to be added to both `gc.h` and `internal/gc.h`, which one is chosen in any particular circumstance seems to be whichever header is already being included for legacy reasons in the `.c` file being edited. I'd like to merge these two files together in order to reduce the cognitive overhead of working on the GC. Am I missing something - are there good reasons why these files should remain separate? -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112295] [Ruby master Feature#17753] Add Module#namespace
by shioyama (Chris Salzberg) 09 Feb '23

09 Feb '23

Issue #17753 has been updated by shioyama (Chris Salzberg). > When you assign an integer to a constant, it's just storage. If you assign a class or module object with a name, it's just storage. However, assigning an anonymous class or module object changes the state, it has a side-effect that is only programmed for these objects. That's a very interesting way to put it, I hadn't thought of it that way. And indeed those side-effects scale with the number of other classes and modules rooted in the thing that was named. ---------------------------------------- Feature #17753: Add Module#namespace https://bugs.ruby-lang.org/issues/17753#change-101730 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal ---------------------------------------- Given code like this: ```ruby module A module B class C; end class D; end end end ``` We can get from `C` to `B` like `C.outer_scope`, or to `A` like `C.outer_scope.outer_scope`. I want to use this in cases where I don't know the outer scope, but I want to find constants that are "siblings" of a constant. For example, I can do `A::B::C.outer_scope.constants` to find the list of "sibling" constants to `C`. I want to use this feature when walking objects and introspecting. For example: ```ruby ObjectSpace.each_object(Class) do |k| p siblings: k.outer_scope.constants end ``` I've attached a patch that implements this feature, and there is a pull request on GitHub [here](https://github.com/ruby/ruby/pull/4326). ---Files-------------------------------- 0001-Add-Module-outer_scope.patch (5.93 KB) 0001-Add-Module-namespace.patch (5.89 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111501] [Ruby master Bug#19283] Regex error on ruby 3.2
by Sho (Shohei Nakano) 09 Feb '23

09 Feb '23

Issue #19283 has been reported by Sho (Shohei Nakano). ---------------------------------------- Bug #19283: Regex error on ruby 3.2 https://bugs.ruby-lang.org/issues/19283 * Author: Sho (Shohei Nakano) * Status: Open * Priority: Normal * ruby -v: 3.2.0 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- There is an regex error pattern on ruby 3.2.0. This pattern is success on ruby 3.1.3. Is this a bug? Or, is ruby 3.2.0 correct? - ruby 3.2.0 ``` # ruby -v ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') nil ``` - ruby 3.1.3 ``` # ruby -v ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux] (byebug) MAX_CHAR_LENGTH = 8 8 (byebug) WHITE_SPACE_STR = '[[:space:]]　\uFEFF\u00A0\u200B\u180E' "[[:space:]]　\\uFEFF\\u00A0\\u200B\\u180E" (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,8}x)|(.{,8}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,8}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> (byebug) MAX_CHAR_LENGTH = 9 9 (byebug) r = /\A((.{,#{MAX_CHAR_LENGTH}}x)|(.{,#{MAX_CHAR_LENGTH}}a[#{WHITE_SPACE_STR}]+b.{,#{MAX_CHAR_LENGTH}}))[#{WHITE_SPACE_STR}]*\Z/ix /\A((.{,9}x)|(.{,9}a[[[:space:]]　\uFEFF\u00A0\u200B\u180E]+b.{,9}))[[[:space:]]　\uFEFF\u00A0\u200B\u180E]*\Z/ix (byebug) r.match('a b') #<MatchData "a b" 1:"a b" 2:nil 3:"a b"> ``` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:111461] [Ruby master Feature#19272] Hash#merge: smarter protocol depending on passed block arity
by zverok (Victor Shepelev) 09 Feb '23

09 Feb '23

Issue #19272 has been reported by zverok (Victor Shepelev). ---------------------------------------- Feature #19272: Hash#merge: smarter protocol depending on passed block arity https://bugs.ruby-lang.org/issues/19272 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- Usage of `Hash#merge` with a "conflict resolution block" is almost always clumsy: due to the fact that the block accepts `|key, old_val, new_val|` arguments, and many trivial usages just somehow sum up old and new keys, the thing that should be "intuitively trivial" becomes longer than it should be: ```ruby # I just want a sum! {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |_, o, n| o + n } # I just want a group! {words: %w[I just]}.merge(words: %w[want a group]) { |_, o, n| [*o, *n] } # I just want to unify flags! {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE) { |_, o, n| o | n } # ...or, vice versa: {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE) { |_, o, n| o & n } ``` It is especially noticeable in the last two examples, but the _usual_ problem is there are too many "unnecessary" punctuation, where the essential might be lost. There are proposals like #19148, which struggle to define _another_ method (what would be the name? isn't it just merging?) But I've been thinking, can't the implementation be chosen based on the arity of the passed block?.. Prototype: ```ruby class Hash alias old_merge merge def merge(other, &block) return old_merge(other) unless block if block.arity.abs != 2 old_merge(other, &block) else old_merge(other) { |_, o, n| block.call(o, n) } end end end {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5, &:+) #=> {:apples=>4, :oranges=>2, :bananas=>5} {words: %w[I just]}.merge(words: %w[want a group], &:concat) => {:words=>["I", "just", "want", "a", "group"]} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, &:|) # => {"file1"=>5, "file2"=>5} {'file1' => File::READABLE, 'file2' => File::READABLE | File::WRITABLE} .merge('file1' => File::WRITABLE, 'file2' => File::WRITABLE, &:&) # => {"file1"=>0, "file2"=>4} # If necessary, old protocol still works: {apples: 1, oranges: 2}.merge(apples: 3, bananas: 5) { |k, o, n| k == :apples ? 0 : o + n } # => {:apples=>0, :oranges=>2, :bananas=>5} ``` As far as I can remember, Ruby core doesn't have methods like this (that change implementation depending on arity of passed callable), but I think I saw this approach in other languages. Can't remember particular examples, but always found this idea appealing. -- https://bugs.ruby-lang.org/

5 8

[ruby-core:112290] [Ruby master Feature#19061] Proposal: make a concept of "consuming enumerator" explicit
by matz (Yukihiro Matsumoto) 09 Feb '23

09 Feb '23

Issue #19061 has been updated by matz (Yukihiro Matsumoto). Regarding the concrete proposals: 1. Introduce an `Enumerator#consuming?` method The consuming information is not reliable especially with I/O (some IO may not be rewindable, but lseek(2) may not return error for the IO, e.g. on MacOS). Thus we cannot implement trust-worthy `consuming?` method 2. Introduce `consuming: true` parameter for Enumerator.new Since `consuming?` state of the enumerators are unreliable, this keyword argument is useless 3. Introduce Enumerator#consuming method to produce a consuming enumerator from a non-consuming one The original PoC code modifies the original, the modified one raising error for duping internal fiber. It's not acceptable behavior (but former may be). In theory, we can overhaul the implementation of enumerators, but I don't think it's worth the cost. The final decision may be up to the actual use-case. But I doubt the benefit. Matz. ---------------------------------------- Feature #19061: Proposal: make a concept of "consuming enumerator" explicit https://bugs.ruby-lang.org/issues/19061#change-101722 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- **The problem** Let's imagine this synthetic data: ```ruby lines = [ "--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators", "", "Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..." ] ``` The logic of parsing it is more or less clear: * skip the first line * take lines until meet empty, to read the header * take the rest of the lines to read the body It can be easily translated into Ruby code, almost literally: ```ruby def parse(enumerator) puts "Testing: #{enumerator.inspect}" enumerator.next p enumerator.take_while { !_1.empty? } p enumerator.to_a end ``` Now, let's try this code with two different enumerators on those lines: ```ruby require 'stringio' enumerator1 = lines.each enumerator2 = StringIO.new(lines.join("\n")).each_line(chomp: true) puts "Array#each" parse(enumerator1) puts puts "StringIO#each_line" parse(enumerator2) ``` Output (as you probably already guessed): ``` Array#each Testing: #<Enumerator: [...]:each> ["--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["--EMAIL--", "From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators", "", "Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] StringIO#each_line Testing: #<Enumerator: #<StringIO:0x00005581018c50a0>:each_line(chomp: true)> ["From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] ``` Only the second enumerator behaves the way we wanted it to. Things to notice here: 1. Both enumerators are of the same class, "just enumerator," but they behave differently: one of them is **consuming** data on each iteration method, the other does not; but there is no programmatic way to tell whether some enumerator instance is consuming 2. There is no easy way to **make a non-consuming enumerator behave in a consuming way**, to open a possibility of a sequence of processing "skip this, take that, take the rest" **Concrete proposal** 1. Introduce an `Enumerator#consuming?` method that will allow telling one of the other (and make core enumerators like `#each_line` properly report they are consuming). 2. Introduce `consuming: true` parameter for `Enumerator.new` so it would be easy for user's code to specify the flag 3. Introduce `Enumerator#consuming` method to produce a consuming enumerator from a non-consuming one: ```ruby # reference implementation is trivial: class Enumerator def consuming source = self Enumerator.new { |y| loop { y << source.next } } end end enumerator3 = lines.each.consuming parse(enumerator3) ``` Output: ``` ["From: zverok.offline(a)gmail.com", "To; bugs(a)ruby-lang.org", "Subject: Consuming Enumerators"] ["Here, I am presenting the following proposal.", "Let's talk about consuming enumerators..."] ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112289] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges
by matz (Yukihiro Matsumoto) 09 Feb '23

09 Feb '23

Issue #18368 has been updated by matz (Yukihiro Matsumoto). I accept solution 2, which someone may specify an array or a set for the range edge, and get an unnatural result. I consider it is the responsibility of the user. Matz. ---------------------------------------- Feature #18368: Range#step semantics for non-Numeric ranges https://bugs.ruby-lang.org/issues/18368#change-101721 * Author: zverok (Victor Shepelev) * Status: Open * Priority: Normal ---------------------------------------- I am sorry if the question had already been discussed, can't find the relevant topic. "Intuitively", this looks (for me) like a meaningful statement: ```ruby (Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a # ^^^^^ or just 24*60*60 ``` Unfortunately, it doesn't work with "TypeError (can't iterate from Time)". Initially it looked like a bug for me, but after digging a bit into code/docs, I understood that `Range#step` has an odd semantics of "advance the begin N times with `#succ`, and yield the result", with N being always integer: ```ruby ('a'..'z').step(3).first(5) # => ["a", "d", "g", "j", "m"] ``` The fact that semantic is "odd" is confirmed by the fact that for Float it is redefined to do what I "intuitively" expected: ```ruby (1.0..7.0).step(0.3).first(5) # => [1.0, 1.3, 1.6, 1.9, 2.2] ``` (Like with [`Range#===` some time ago](https://bugs.ruby-lang.org/issues/14575), I believe that to be a strong proof of the wrong generic semantics, if for numbers the semantics needed to be redefined completely.) Another thing to note is that "skip N elements" seem to be rather "generically Enumerable-related" yet it isn't defined on `Enumerable` (because nobody needs this semantics, typically!) Hence, two questions: * Can we redefine generic `Range#step` to new semantics (of using `begin + step` iteratively)? It is hard to imagine the amount of actual usage of the old behavior (with String?.. to what end?) in the wild * If the answer is "no", can we define a new method with new semantics, like, IDK, `Range#over(span)`? **UPD:** More examples of useful behavior (it is NOT only about core `Time` class): ```ruby require 'active_support/all' (1.minute..20.minutes).step(2.minutes).to_a #=> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13 minutes, 15 minutes, 17 minutes, 19 minutes] require 'tod' (Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes).to_a #=> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeOfDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>] require 'matrix' (Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3) #=> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]] require 'unitwise' (Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s) #=> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km", "7/10 km", "4/5 km", "9/10 km", "1 km"] ``` **UPD:** Responding to discussion points: **Q:** Matz is concerned that the proposed simple definition will be confusing with the classes where `+` is redefined as concatenation. **A:** I believe that simplicity of semantics and ease of explaining ("it just uses `+` underneath, whatever `+` does, will be performed") will make the confusion minimal. **Q:** Why not introduce new API requirement (like "class of range's `begin` should implement `increment` method, and then it will be used in `step`) **A:** require *every* gem author to change *every* of their objects' behavior. For that, they should be aware of the change, consider it important enough to care, clearly understand the necessary semantics of implementation, have a resource to release a new version... Then all users of all such gems would be required to upgrade. The feature would be DOA (dead-on-arrival). The two alternative ways I am suggesting: change the behavior of `#step` or introduce a new method with desired behavior: 1. Easy to explain and announce 2. Require no other code changes to immediately become useful 3. With something like [backports](https://github.com/marcandre/backports) or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using even in older Ruby version, making the code more expressive even before it would be possible for some particular app/compny to upgrade to (say) 3.2 All examples of behavior from the code above are real `irb` output with monkey-patched `Range#step`, demonstrating how little change will be needed to code outside of the `Range`. -- https://bugs.ruby-lang.org/

1 0