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

[ruby-core:116438] [Ruby master Feature#20211] Reconsider introducing 3.2-style support of Anonymous Args/Blocks
by johnnyshields (Johnny Shields) 25 Jan '24

25 Jan '24

Issue #20211 has been reported by johnnyshields (Johnny Shields). ---------------------------------------- Feature #20211: Reconsider introducing 3.2-style support of Anonymous Args/Blocks https://bugs.ruby-lang.org/issues/20211 * Author: johnnyshields (Johnny Shields) * Status: Open * Priority: Normal ---------------------------------------- (My sincere apologies if this issue has already been raised, I didn't see it in Ruby 3.4 backlog.) As per https://bugs.ruby-lang.org/issues/19370, Ruby 3.3 no longer allows the following: ```ruby def m(*) [1, 2, 3].each { |*| p(*) } end m('test', 'test', 'test') #=> Ruby 3.2: p(*) uses args from m(*) #=> test, test, test #=> Ruby 3.3: raises SyntaxError: anonymous rest parameter is also used within block ``` I am concerned because Rubocop auto-corrects Ruby 3.1+ code to syntax which is no longer supported in Ruby 3.3. There may be quite a bit of Ruby code in the wild which breaks on 3.3 (my own app broke in about 50 places). - [Ruby 3.1+: Naming/BlockForwarding (default true)](https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Naming/BlockForwarding) - [Ruby 3.2+: Style/ArgumentsForwarding with UseAnonymousForwarding (default true)](https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/ArgumentsForwarding) It would be nice if the Ruby 3.4 syntax could allow the old nested syntax, supporting arg shadowing with different behavior between implicit and explicit |*| usage. ```ruby def m(*) [1, 2, 3].each { p(*) } end m('test', 'test', 'test') #=> Ruby 3.2: p(*) uses args from m(*) #=> test, test, test #=> Ruby 3.4: p(*) uses args from m(*) #=> test, test, test def m(*) [1, 2, 3].each { |*| p(*) } end m('test', 'test', 'test') #=> Ruby 3.2: p(*) uses args from m(*) #=> test, test, test #=> Ruby 3.4: p(*) uses args from each #=> 1, 2, 3 ``` The same would also apply to anonymous blocks. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115749] [Ruby master Feature#20066] Reduce Implicit Array/Hash Allocations For Method Calls Involving Splats
by jeremyevans0 (Jeremy Evans) 25 Jan '24

25 Jan '24

Issue #20066 has been reported by jeremyevans0 (Jeremy Evans). ---------------------------------------- Feature #20066: Reduce Implicit Array/Hash Allocations For Method Calls Involving Splats https://bugs.ruby-lang.org/issues/20066 * Author: jeremyevans0 (Jeremy Evans) * Status: Open * Priority: Normal ---------------------------------------- I have submitted a pull request (https://github.com/ruby/ruby/pull/9247) to reduce implicit array and hash allocations for method calls involving splats. The following optimizations are included: VM_CALL_ARGS_SPLAT_MUT callinfo flag This is similar to the VM_CALL_KW_SPLAT_MUT flag added in Ruby 3.0. This makes it so if the caller-side allocates an array for the method call, the flag is used to signal to the callee that it can reuse the allocated array and does not need to duplicate it. concattoarray VM instruction This instruction is similar to concatarray, but assumes the object being concatenated to is already a mutable array (such as those created by the splatarray VM instruction). This optimizes method calls with multiple splats such as `f(*a,*a,*a)` (which previously allocated 3 arrays), allocating a single array instead of an array per splatted array. pushtoarray VM instruction This is similar, but handles non-splat arguments after a splat. Previously, the VM would wrap those arguments in an array using newarray, and then call concatarray, such that `f(*a, a)` allocated 3 arrays caller-side. This instruction just appends to the mutable array, reducing the number of arrays allocated to 1. Allocationless Anonymous Splat Forwarding This allows `def f(*, **) end` to not allocate an array or hash callee side. This works because it is not possible to mutate the local variables, only pass them as splats to other methods. This can make the following call chain allocation less: ```ruby def f(a, b: 1) end def g(*, **) f(*, **) end ea a = [1] kw = {b: 2} g(*a, **kw) # No allocations in this call ``` Switch ... argument forwards to not use ruby2_keywords Using ruby2_keywords has probably been slower since Koichi's changes early in the Ruby 3.3 development cycle to not combine keyword splats into the positional splat array. This removes the FORWARD_ARGS_WITH_RUBY2_KEYWORDS define, so that `def f(...) end` operates similarly to `def f(*, **) end`, allowing allocationless splat forwarding Reduce array and hash allocations for nested argument forwarding calls This uses a combination of frame flags and callinfo flags to track mutability of anonymous splat variables. It can make it so the following call example only allocates a 1 array and 1 hash: ```ruby def m1(*args, **kw) end def m2(...) m1(...) end def m3(*, **) m2(*, **) end m3(1, a: 1) # 1 array and 1 hash allocated ``` In the above example, the call to `m3` allocates an array (`[1]`) and a hash (`{a: 1}`), but the call to `m2` passes them as mutable splats, `m2` treats them as mutable splats when calling `m1`, and `m1` reuses the array that `m3` allocated for `args` and the hash that `m3` allocated for `kw`. I created a benchmark for all of these changes. In the method calls optimized by these changes, it is significantly faster: ``` named_multi_arg_splat after: 5344097.6 i/s before: 3088134.0 i/s - 1.73x slower named_post_splat after: 5401882.3 i/s before: 2629321.8 i/s - 2.05x slower anon_arg_splat after: 12242780.9 i/s before: 6845413.2 i/s - 1.79x slower anon_arg_kw_splat after: 11277398.7 i/s before: 4329509.4 i/s - 2.60x slower anon_multi_arg_splat after: 5132699.5 i/s before: 3018103.7 i/s - 1.70x slower anon_post_splat after: 5602915.1 i/s before: 2645185.5 i/s - 2.12x slower anon_kw_splat after: 15403727.3 i/s before: 6249504.6 i/s - 2.46x slower anon_fw_to_named_splat after: 2985715.3 i/s before: 2049159.9 i/s - 1.46x slower anon_fw_to_named_no_splat after: 2941030.4 i/s before: 2100380.0 i/s - 1.40x slower fw_to_named_splat after: 2801008.7 i/s before: 2012416.4 i/s - 1.39x slower fw_to_named_no_splat after: 2742670.4 i/s before: 1957707.2 i/s - 1.40x slower fw_to_anon_to_named_splat after: 2309246.6 i/s before: 1375924.6 i/s - 1.68x slower fw_to_anon_to_named_no_splat after: 2193227.6 i/s before: 1351184.1 i/s - 1.62x slower ``` Only fallout from these changes: * Minor change to AST output for `...` not using `ruby2_keywords` * Prism and rbs need updating for `...` not using `ruby2_keywords` * typeprof need updating for new VM instructions (at least pushtoarray) VM_CALL_ARGS_SPLAT_MUT, concattoarray, and pushtoarray only affect uncommon callsites (multiple splats, argument after splat). Other commits only optimize calls to methods using anonymous splats or `...` argument forwarding. Previously, there was no performance reason to use anonymous splats or `...` argument forwarding, but with this change, using them can be faster, and can offer a new way for users to optimize their code. In my opinion, this is too late for consideration in Ruby 3.3, but it could be considered for Ruby 3.4. -- https://bugs.ruby-lang.org/

4 18

[ruby-core:116278] [Ruby master Misc#20191] Deprecate magic encoding comment
by kddnewton (Kevin Newton) 24 Jan '24

24 Jan '24

Issue #20191 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Misc #20191: Deprecate magic encoding comment https://bugs.ruby-lang.org/issues/20191 * Author: kddnewton (Kevin Newton) * Status: Open * Priority: Normal ---------------------------------------- I would like to ask that we deprecate the magic encoding comment, and instead require all source files to be encoded in UTF-8. There would be many benefits to the performance of both the parser and compiler. It would also help to simplify both. For example, right now a string literal in a file encoded in US-ASCII can result in 3 different encodings, depending on its internal bytes. If the file is encoded in UTF-8, it can only be a UTF-8 string. The encoding comment itself is not very commonly used in gems. If you take the top 100 most downloaded gem versions from rubygems.org and look at the resolved encoding of all of the files, you get: - UTF-8: 11554 - ASCII-8BIT: 35 - US-ASCII: 10 For all of the most recent versions of gems on rubygems.org, you get: - UTF-8: 2967421 - US-ASCII: 20130 - ASCII-8BIT: 9237 - ISO-8859-1: 87 - Windows-1252: 45 - Shift_JIS: 32 - Windows-31J: 22 - Windows-1251: 15 - EUC-JP: 11 - GBK: 4 - KOI8-R: 3 - ISO-8859-15: 2 - UTF8-MAC: 1 - invalid: 33 Note that "invalid" here could have worked on some rubies < 3.2 if they used Encoding#replicate. If we were to change this, the main breaking change concern would be the encoding of strings and symbols that would leave the context of the file by virtue of a constant read/method call. That's why I think it should first be deprecated in a minor release, then removed in the next major. At the moment this would mean for the top 100 gems we would be worried about 0.39% of files, and on rubygems.org as a whole we would be worried about 0.99% of files. If deprecating the entire encoding comment is unacceptable from a compatibility point of view, I would suggest we try only allowing UTF-8, US-ASCII, and ASCII-8BIT. This would still have a lot of value/simplifications/performance opportunities, at the expense of still needing to be parsed and checked. On the top 100 gems this would mean no files would have to change, and on rubygems.org as a whole it would mean we would be worried about 0.009% of files. That being said, if we're going to deprecate this at all, we should probably just do it all the way to get the full benefit. (In case you want to check the math, the script used to calculate these is attached.) ---Files-------------------------------- gems.rb (4.33 KB) -- https://bugs.ruby-lang.org/

6 6

[ruby-core:116413] [Ruby master Feature#16049] optimization for frozen dynamic string literals "#{exp}".dup and +"#{exp}"
by Dan0042 (Daniel DeLorme) 24 Jan '24

24 Jan '24

Issue #16049 has been updated by Dan0042 (Daniel DeLorme). Dynamic string literals are not longer frozen, this can be closed. (Would it be possible for the author to close their own ticket?) ---------------------------------------- Feature #16049: optimization for frozen dynamic string literals "#{exp}".dup and +"#{exp}" https://bugs.ruby-lang.org/issues/16049#change-106435 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- When the decision was made that `frozen_string_literal: true` should also apply to dynamic string literals, it was mitigated with the following explanation: > "#{exp}".dup can be optimized so it won’t allocate extra objects like "...".freeze https://docs.google.com/document/u/1/d/1D0Eo5N7NE_unIySOKG9lVj_eyXf66BQPM4P… However that does not appear to be the case currently. Using this script that generates 100k String objects: ```ruby # frozen_string_literal: true def allocated GC.stat[:total_allocated_objects] end GC.disable c = ARGV.shift.to_sym x_eq_i = ARGV.shift=="i" x = "x" before = allocated 100_000.times do |i| x = i.to_s if x_eq_i case c when :normal then v = "#{x}" when :freeze then v = "#{x}".freeze when :minus then v = -"#{x}" when :dup then v = "#{x}".dup when :plus then v = +"#{x}" else raise end end after = allocated printf "%d\n", after-before ``` I get the following number of objects allocated ``` x= frozen_string_literal normal freeze minus dup plus 'x' false 100001 100001 100001 200001 100001 'x' true 100001 100001 100001 200001 200001 i false 200001 200001 299999 300001 200001 i true 200001 200001 200001 300001 300001 ``` We can see that `"#{x}".dup` and `+"#{x}"` allocate an extra object per iteration I also tested with `x = i.to_s` to see if deduplication of 100k identical strings was different from 100k different strings. In addition to the expected extra strings created by `i.to_s`, there's an additional 100k extra strings created for `-"#{i}"` when frozen_string_literal is false??? There may also be a memory leak here because while the number of objects increases by x3, memory usage increases by x4. Summary: I expected `"#{v}".dup` and `+"#{v}"` to behave the same regardless of frozen_string_literal (and optimize down to just one allocation) I expected `"#{v}".freeze` and `-"#{v}"` to behave the same regardless of frozen_string_literal (and optimize down to just one allocation) but they do not. I think they should. It would be nice. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116393] [Ruby master Feature#18576] Rename `ASCII-8BIT` encoding to `BINARY`
by shyouhei (Shyouhei Urabe) 24 Jan '24

24 Jan '24

Issue #18576 has been updated by shyouhei (Shyouhei Urabe). @naruse is actually positive for changing error messages (see #note-28). I guess everybody here is agreeing to @byroot's list of proposed changes in #note-37 (except wording)? ---------------------------------------- Feature #18576: Rename `ASCII-8BIT` encoding to `BINARY` https://bugs.ruby-lang.org/issues/18576#change-106416 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Target version: 3.4 ---------------------------------------- ### Context I'm now used to it, but something that confused me for years was errors such as: ```ruby >> "fée" + "\xFF".b (irb):3:in `+': incompatible character encodings: UTF-8 and ASCII-8BIT (Encoding::CompatibilityError) ``` When you aren't that familiar with Ruby, it's really not evident that `ASCII-8BIT` basically means "no encoding" or "binary". And even when you know it, if you don't read carefully it's very easily confused with `US-ASCII`. The `Encoding::BINARY` alias is much more telling IMHO. ### Proposal Since `Encoding::ASCII_8BIT` has been aliased as `Encoding::BINARY` for years, I think renaming it to `BINARY` and then making asking `ASCII_8BIT` the alias would significantly improve usability without backward compatibility concerns. The only concern I could see would be the consistency with a handful of C API functions: - `rb_encoding *rb_ascii8bit_encoding(void)` - `int rb_ascii8bit_encindex(void)` - `VALUE rb_io_ascii8bit_binmode(VALUE io)` But that's for much more advanced users, so I don't think it's much of a concern. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116028] [Ruby master Feature#20152] mkmf / extconf: Add a proper way to not compile the extension
by byroot (Jean Boussier) 24 Jan '24

24 Jan '24

Issue #20152 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20152: mkmf / extconf: Add a proper way to not compile the extension https://bugs.ruby-lang.org/issues/20152 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context There are various gems that ship with a native extension as a way to speedup part of the gem, but also ship with a pure Ruby version of these methods as a fallback. So they only want to compile the extension if the platform supports it, and if not, just fallback to the slightly slower Ruby version. Right now users rely on one of two hacks to do this. Either they create an empty Makefile, but then still depend on `make` being available, or publish platform specific packages without any extension in them. Examples: - [`bootsnap` skip compilation if not on MRI or TruffleRuby](https://github.com/Shopify/bootsnap/blob/070151f1305f23102365d… - [`erb` has an extension for MRI but then need to publish a `java` version of the gem that doesn't actually contain Java code, just to skip compilation on JRuby](https://github.com/ruby/erb/issues/52) - [`hiredis-client` skips the compilation for Windows and non-MRI rubies](https://github.com/redis-rb/redis-client/blob/1ab081c1d0e47df5d55e0… ### Feature It would be very useful to have some proper first class API to skip compiling the extension. Something like: ```ruby require "mkmf" if RUBY_ENGINE != "ruby" || RUBY_PLATFORM.match?(/mswin/) skip_compilation else # ... end ``` cc @k0kubun @headius -- https://bugs.ruby-lang.org/

10 20

[ruby-core:116379] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by Eregon (Benoit Daloze) 24 Jan '24

24 Jan '24

Issue #19057 has been updated by Eregon (Benoit Daloze). Agreed, from the hardware POV it has to store the struct in a reasonable/consistent manner in memory. I would be more worried about the C compiler, if the C compiler figures out a pointer is casted to "unrelated" struct types it might consider that as undefined behavior and do anything. But I suspect that's explicitly not undefined behavior, because C has no notion of struct types being related or not, and there is likely tons of software using structs "inheriting/extending" another smaller struct. It might not explicitly be allowed either because I guess the fully correct way to do this is using a union of both structs, and not casting to a specific struct directly then. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-106396 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:116388] [BUG] leak in deprecated Data_Make_Struct
by Eric Wong 24 Jan '24

24 Jan '24

I can't open new bug on Redmine due to TOTP so I'll post here. (I'm not going to run JS, view images, or deal with proprietary tools/services). I realize Data_Make_Struct is deprecated and I'm updating a gem to TypedData, there's likely old code which is affected by this leak. With the patch below to make data_spec.c use Data_Make_Struct, this script leaks: $LOAD_PATH << './spec/ruby/optional/capi/ext' require 'data_spec' loop { CApiAllocSpecs.Data_Make_Struct } I noticed this on Ruby 3.3 (32-bit x86) with `clogger' RubyGem, and also up to recent master commit c0cabc0a699b2c8b (Dump annotations on RubyVM::ISeq.disasm (#9667), 2024-01-23) --- Not sure how to write a Ruby spec for malloc memory leaks but I'm just a drive by contributor at this point. It takes me 2-3 hours to build and test Ruby on my old system so I don't feel like doing more. spec/ruby/optional/capi/ext/data_spec.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/spec/ruby/optional/capi/ext/data_spec.c b/spec/ruby/optional/capi/ext/data_spec.c index ef069ef0ba..450eef6c76 100644 --- a/spec/ruby/optional/capi/ext/data_spec.c +++ b/spec/ruby/optional/capi/ext/data_spec.c @@ -24,6 +24,11 @@ VALUE sdaf_alloc_func(VALUE klass) { return Data_Wrap_Struct(klass, &sample_wrapped_struct_mark, &sample_wrapped_struct_free, bar); } +VALUE sdaf_make_struct(VALUE klass) { + struct sample_wrapped_struct* bar; + return Data_Make_Struct(klass, struct sample_wrapped_struct, sample_wrapped_struct_mark, RUBY_DEFAULT_FREE, bar); +} + VALUE sdaf_get_struct(VALUE self) { struct sample_wrapped_struct* bar; Data_Get_Struct(self, struct sample_wrapped_struct, bar); @@ -74,6 +79,7 @@ VALUE sws_rb_check_type(VALUE self, VALUE obj, VALUE other) { void Init_data_spec(void) { VALUE cls = rb_define_class("CApiAllocSpecs", rb_cObject); rb_define_alloc_func(cls, sdaf_alloc_func); + rb_define_singleton_method(cls, "Data_Make_Struct", sdaf_make_struct, 0); rb_define_method(cls, "wrapped_data", sdaf_get_struct, 0); cls = rb_define_class("CApiWrappedStructSpecs", rb_cObject); rb_define_method(cls, "wrap_struct", sws_wrap_struct, 1);

1 0

[ruby-core:116381] [Ruby master Feature#8506] Object#iter_for / Object#to_iter
by Eregon (Benoit Daloze) 23 Jan '24

23 Jan '24

Issue #8506 has been updated by Eregon (Benoit Daloze). Status changed from Open to Rejected Right, so given they do the same or very similar, let's close this. ---------------------------------------- Feature #8506: Object#iter_for / Object#to_iter https://bugs.ruby-lang.org/issues/8506#change-106398 * Author: alindeman (Andy Lindeman) * Status: Rejected * Priority: Normal ---------------------------------------- =begin Ruby's (({Enumerator})) and (({#enum_for})) methods are very powerful and I use them very often. However, (({Object#enum_for})) requires a method that yields, usually in some sort of loop. Many objects in Ruby have methods that iterate to a "next value," but do not yield. For example, (({Fixnum#next.})) There is no way to use (({Fixnum#next})) with (({#enum_for})) directly that I am aware of. I propose the introduction of (({Object#iter_for})) which--given a method--generates a lazy sequence by continually invoking the method on successive values. I call it (({iter})) or (({iterate})) because it is very similar to clojure's iterate: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/iterate Proposed API: 0.iter_for(:next).take(5) # => [0, 1, 2, 3, 4] require 'date' Date.new(2013, 1, 1).iter_for(:next_month).take(3) # => [Tue, 01 Jan 2013, Fri, 01 Feb 2013, Fri, 01 Mar 2013] I am especially excited about (({0.iter_for(:next)})) as I find myself using infinite lazy numeric sequences more often lately to solve specific kinds of problems. Right now you are required to write something like: (({Enumerator.new { |y| i = 0; loop { y << i; i += 1 } }})) or (({(0..Float::INFINITY).each})). Neither is especially elegant or happy to the developers' eyes in my opinion. Thank you all :) Ruby is an amazing tool. =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:116380] [Ruby master Feature#8506] Object#iter_for / Object#to_iter
by p8 (Petrik de Heus) 23 Jan '24

23 Jan '24

Issue #8506 has been updated by p8 (Petrik de Heus). ``` 0.iter_for(:next).take(5) # => [0, 1, 2, 3, 4] ```ruby Enumerator.produce(0, &:succ).take(5) => [0, 1, 2, 3, 4] Enumerator.produce(Date.new(2013, 1, 1), &:next_month).take(3) => [Tue, 01 Jan 2013, Fri, 01 Feb 2013, Fri, 01 Mar 2013] ``` ---------------------------------------- Feature #8506: Object#iter_for / Object#to_iter https://bugs.ruby-lang.org/issues/8506#change-106397 * Author: alindeman (Andy Lindeman) * Status: Open * Priority: Normal ---------------------------------------- =begin Ruby's (({Enumerator})) and (({#enum_for})) methods are very powerful and I use them very often. However, (({Object#enum_for})) requires a method that yields, usually in some sort of loop. Many objects in Ruby have methods that iterate to a "next value," but do not yield. For example, (({Fixnum#next.})) There is no way to use (({Fixnum#next})) with (({#enum_for})) directly that I am aware of. I propose the introduction of (({Object#iter_for})) which--given a method--generates a lazy sequence by continually invoking the method on successive values. I call it (({iter})) or (({iterate})) because it is very similar to clojure's iterate: http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/iterate Proposed API: 0.iter_for(:next).take(5) # => [0, 1, 2, 3, 4] require 'date' Date.new(2013, 1, 1).iter_for(:next_month).take(3) # => [Tue, 01 Jan 2013, Fri, 01 Feb 2013, Fri, 01 Mar 2013] I am especially excited about (({0.iter_for(:next)})) as I find myself using infinite lazy numeric sequences more often lately to solve specific kinds of problems. Right now you are required to write something like: (({Enumerator.new { |y| i = 0; loop { y << i; i += 1 } }})) or (({(0..Float::INFINITY).each})). Neither is especially elegant or happy to the developers' eyes in my opinion. Thank you all :) Ruby is an amazing tool. =end -- https://bugs.ruby-lang.org/

1 0