February 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112313] [Ruby master Feature#19428] Adding a "piped heredoc" feature
by shreeve (Steve Shreeve) 20 Feb '23

20 Feb '23

Issue #19428 has been reported by shreeve (Steve Shreeve). ---------------------------------------- Feature #19428: Adding a "piped heredoc" feature https://bugs.ruby-lang.org/issues/19428 * Author: shreeve (Steve Shreeve) * Status: Open * Priority: Normal ---------------------------------------- Hello, I hope this is the correct place to post a small feature request. HEREDOC's are awesome! There are several used within Ruby: ```ruby <<END Have to left justify this END <<-INDENTED Still left justified, but indented ending INDENTED <<~SQUIGGLY I can indent content it will be smartly "dedented/undented". Looks nicer. SQUIGGLY ``` I love using the SQUIGGLY heredoc, which will strip off the minimum whitespace from the front of each line in the heredoc. I often do something like this: ```ruby options = { name: "My Nice Options", description: <<~END This is a cool set of options. You Can put what you like here. END } ``` If you need to continue with the above, you can add a comma after like this: ```ruby options = { name: "My Nice Options", description: <<~END, This is a cool set of options. You Can put what you like here. END details: <<~END, Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. END } ``` You can even get a little squirrely and use an empty string for a heredoc terminator: ```ruby options = { name: "My Nice Options", description: <<~"", This is a cool set of options. You Can put what you like here. details: <<~"", Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. } ``` There's one variation that I think would be nice to add, I call it a "piped heredoc". It would essentially work like the squiggly heredoc, but the "terminator" would be the next line that is not indented, and thus not "part of the heredoc". Here's an example: ```ruby options = { name: "My Nice Options", description: <<|, This is a cool set of options. You Can put what you like here. details: <<|, Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. } ``` Since the leading whitespace is used to tell when the heredoc ends, there is no need for an explicit terminator. You could add one if you'd like to indicate the flavor of the content, for syntax highlighters, but it's value is ignored: ```ruby options = { name: "My Nice Options", description: <<|RUBY, users.each do |user| user.pay_daily_bonus! end details: <<|, Some more stuff here... This will only be indented 2 spaces. And this 4 spaces. And this 2 spaces again. Back to the "left" side. } ``` In the above, the "RUBY" is not really needed, but it is a hint to format that block as Ruby code. This tweak to Ruby's heredocs seems like it could make Ruby syntax easy and fun to read. -- https://bugs.ruby-lang.org/

4 6

[ruby-core:112493] RUBY_PLATFORM shows `x32' on `x86' userspace
by Eric Wong 19 Feb '23

19 Feb '23

Not sure it's a bug or not, but it probably is... My RUBY_PLATFORM is `x86_64-linux-x32' nowadays (it was only `x86_64-linux' previously, but that was also inaccurate). I'm running x86_64 Linux kernel, but a Debian i386 userspace (really i486). x32 is newer, better 32-bit userspace mode for 64-bit kernels. However, x32 is basically abandoned due to lack of adoption, so I keep using i[3-6]86. $ file ./ruby ./ruby: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=fc8fe2291ef2987e717248b777ef4a130dca9251, for GNU/Linux 3.2.0, with debug_info, not stripped $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/10/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=i686-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-targets=all --enable-multiarch --disable-werror --with-arch-32=i686 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.2.1 20210110 (Debian 10.2.1-6) *shrug*

1 0

[ruby-core:112492] [Ruby master Feature#19024] Proposal: Import Modules
by shioyama (Chris Salzberg) 19 Feb '23

19 Feb '23

Issue #19024 has been updated by shioyama (Chris Salzberg). I wanted to update this because I've changed my thinking since the original proposal. TL;DR 1. I agree that we should not change `require`, `require_relative`, `load` or `autoload` (at least, not in ways that would break existing usage). Thanks @jeremyevans0 and others for convincing me of this. 2. Any new way to import code should be _opt-in_. Again, many voiced this opinion here and it makes sense to me now. I decided to take these two as constraints and see what else was possible in Ruby 3.2, and came up with (a new version of) [Im](https://github.com/shioyama/im). Im is an "isolated module autoloader", a fork of Zeitwerk which autoloads constants under an anonymous namespace. The interface for Im is nearly identical to Zeitwerk except that rather than loading to top-level, constants are loaded under loaders themselves, where `Im::Loader` subclasses `Module` and can therefore define its own namespace. So for gem code, it looks like this: ```ruby # lib/my_gem.rb (main file) require "im" loader = Im::Loader.for_gem loader.setup # ready! module loader::MyGem # ... end loader.eager_load # optionally ``` Notice here that `loader` encapsulates the entire loaded namespace. Further details in the [readme](https://github.com/shioyama/im/blob/main/README.md). I've also built a [sample Rails app](https://bugs.ruby-lang.org/issues/17881) which uses Im to load all its code under a single application namespace. Internally Im uses `load` with the second module argument (discussed here) and also `Module#const_added` ([ref](https://bugs.ruby-lang.org/issues/17881)) also added in Ruby 3.2. The advantages to this approach: - autoloading does not require "returning" anything, unlike `require`, where any change would face the problem of where to "receive" the thing you've loaded if not at toplevel. For the most part you can just write your code exactly as you would any other Zeitwerk-autoloaded code, without any `import` calls in each file, and for a gem you just `import` the gem once and get the whole tree of autoloaded code. - the Zeitwerk convention for file naming/loading (inherited from Rails) is now widely adopted, and so the changes to make a gem "Im-compatible" should generally be quite small. (The exception here is Rails, which depends heavily on `Module#name` to map association names, etc.) - Although the approach does not guarantee isolation (e.g. you can always "break out" by referencing toplevel with `::Foo`), it _can_ guarantee a kind of "opt-in" isolation, whereby _within your autoloaded code you own the toplevel (because your "toplevel" is the top of an anonymous-rooted module namespace). Similarly, a gem can entirely remove itself from the global namespace, instead allowing the gem consumer to determine the top constant name under which to load code. So two gems that follow the convention are isolated from each other provided they don't create/modify anything at the "absolute toplevel". @rubyFeedback > This can lead to problems sometimes. I agree it is not a huge problem per se I disagree here, I think this is actually a huge issue, and I think it's only because we as Rubyists are so used to it that we treat it as a "minor" inconvenience. It's fundamentally a scaling issue both in the code ecosystem space (rubygems) and in the application space. As you noted, it's not just a problem that "my constant collides with your constant with the same name". It's that _every_ pair of collaborators in an application (every pair of gems in the `Gemfile`, plus every contributor to the application itself) have to follow a contract that says nobody will modify the same namespace in "unexpected" ways. When you start scaling things up, to an application with thousands of contributors with hundreds of gems, this becomes problematic at best. I think Im is a potential solution to this problem. Moreover, allaying I think some of the concerns expressed here, a gem can opt to offer two "endpoints", one for Zeitwerk and one for Im, such that the gem consumer can decide how to "consume" the gem code (either at toplevel or under an anonymous-rooted namespace). So if you like your universe always pointing to the same toplevel, it would be possible to keep that, whereas others who want to "relativize" the toplevel would also be able to do that. In any case, I don't really feel the need for further changes to Ruby other than any supporting the existing functionality in 3.2. I'm happy if this is closed, unless others want to keep it open. ---------------------------------------- Feature #19024: Proposal: Import Modules https://bugs.ruby-lang.org/issues/19024#change-101935 * Author: shioyama (Chris Salzberg) * Status: Open * Priority: Normal ---------------------------------------- There is no general way in Ruby to load code outside of the globally-shared namespace. This makes it hard to isolate components of an application from each other and from the application itself, leading to complicated relationships that can become intractable as applications grow in size. The growing popularity of a gem like [Packwerk](https://github.com/shopify/packwerk), which provides a new concept of "package" to enforce boundaries statically in CI, is evidence that this is a real problem. But introducing a new packaging concept and CI step is at best only a partial solution, with downsides: it adds complexity and cognitive overhead that wouldn't be necessary if Ruby provided better packaging itself (as Matz has suggested [it should](https://youtu.be/Dp12a3KGNFw?t=2956)). There is _one_ limited way in Ruby currently to load code without polluting the global namespace: `load` with the `wrap` parameter, which as of https://bugs.ruby-lang.org/issues/6210 can now be a module. However, this option does not apply transitively to `require` calls within the loaded file, so its usefulness is limited. My proposal here is to enable module imports by doing the following: 1. apply the `wrap` module namespace transitively to `require`s inside the loaded code, including native extensions (or provide a new flag or method that would do this), 2. make the `wrap` module the toplevel context for code loaded under it, so `::Foo` resolves to `<top_wrapper>::Foo` in loaded code (or, again, provide a new flag or method that would do this). _Also make this apply when code under the wrapper module is called outside of the load process (when `top_wrapper` is no longer set) — this may be quite hard to do_. 3. resolve `name` on anonymous modules under the wrapped module to their names without the top wrapper module, so `<top_wrapper>::Foo.name` evaluates to `"Foo"`. There may be other ways to handle this problem, but a gem like Rails uses `name` to resolve filenames and fails when anonymous modules return something like `#<Module: ...>::ActiveRecord` instead of just `ActiveRecord`. I have roughly implemented these three things in [this patch](https://github.com/ruby/ruby/compare/master...shioyama:ruby:import_m…. This implementation is incomplete (it does not cover the last highlighted part of 2) but provides enough of a basis to implement an `import` method, which I have done in a gem called [Im](https://github.com/shioyama/im). Im provides an `import` method which can be used to import gem code under a namespace: ```ruby require "im" extend Im active_model = import "active_model" #=> <#Im::Import root: active_model> ActiveModel #=> NameError active_model::ActiveModel #=> ActiveModel active_record = import "active_record" #=> <#Im::Import root: active_record> # Constants defined in the same file under different imports point to the same objects active_record::ActiveModel == active_model::ActiveModel #=> true ``` With the constants all loaded under an anonymous namespace, any code importing the gem can name constants however it likes: ```ruby class Post < active_record::ActiveRecord::Base end AR = active_record::ActiveRecord Post.superclass #=> AR::Base ``` Note that this enables the importer to completely determine the naming for every constant it imports. So gems can opt to hide their dependencies by "anchoring" them inside their own namespace, like this: ```ruby # in lib/my_gem.rb module MyGem dep = import "my_gem_dependency" # my_gem_dependency is "anchored" under the MyGem namespace, so not exposed to users # of the gem unless they also require it. MyGemDependency = dep #... end ``` There are a couple important implementation decisions in the gem: 1. _Only load code once._ When the same file is imported again (either directly or transitively), "copy" constants from previously imported namespace to the new namespace using a registry which maps which namespace (import) was used to load which file (as shown above with activerecord/activemodel). This is necessary to ensure that different imports can "see" shared files. A similar registry is used to track autoloads so that they work correctly when used from imported code. 2. Toplevel core types (`NilClass`, `TrueClass`, `FalseClass`, `String`, etc) are "aliased" to constants under each import module to make them available. Thus there can be side-effects of importing code, but this allows a gem like Rails to monkeypatch core classes which it needs to do for it to work. 3. `Object.const_missing` is patched to check the caller location and resolve to the constant defined under an import, if there is an import defined for that file. To be clear: **I think 1) should be implemented in Ruby, but not 2) and 3).** The last one (`Object.const_missing`) is a hack to support the case where a toplevel constant is referenced from a method called in imported code (at which point the `top_wrapper` is not active.) I know this is a big proposal, and there are strong opinions held. I would really appreciate constructive feedback on this general idea. Notes from September's Developers Meeting: https://github.com/ruby/dev-meeting-log/blob/master/DevMeeting-2022-09-22.m… See also similar discussion in: https://bugs.ruby-lang.org/issues/10320 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112477] [Ruby master Bug#19448] [Hash] Using Set as default value
by bobanj (Boban Jovanoski) 18 Feb '23

18 Feb '23

Issue #19448 has been reported by bobanj (Boban Jovanoski). ---------------------------------------- Bug #19448: [Hash] Using Set as default value https://bugs.ruby-lang.org/issues/19448 * Author: bobanj (Boban Jovanoski) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-darwin22] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- When using a hash and set is used as a default value, the keys method for the hash does not return expected values. A workaround for this is provided in the attachment. ---Files-------------------------------- bug.rb (382 Bytes) -- https://bugs.ruby-lang.org/

4 4

[ruby-core:112482] [Ruby master Feature#18597] Strings need a named method like `dup` that doesn't duplicate if receiver is mutable
by danh337 (Dan H) 17 Feb '23

17 Feb '23

Issue #18597 has been updated by danh337 (Dan H). rubyFeedback (robert heiler) wrote in #note-18: > > And it feels like I cannot convince anyone here with any amount of rationale > > Ultimately you only have to convince matz, so you could ignore what others write. > > But one reason why there was a reference to real-needs above is that the ruby > core/dev team said that they focus on real needs (although they may evaluate > what is real and what is not ultimately, as well as the cost of addition of > methods). > > My personal opinion is that, usage aside, the .dup_if_immutable feels very clunky. > [...] This is a great response, cheers and thanks for your time. Honestly I never thought this was a huge thing, and in fact we already fixed it with the "thaw" method I mentioned in comment #13 above. It was an issue that came up for me, integrating with old code, in a couple different ways, but the team considers it solved now. I think I confused the issue early on, not clearly describing the issue for Strings first, then generalizing to Object. As usual the Ruby community has some cool and helpful folks, thanks again for responding here. ---------------------------------------- Feature #18597: Strings need a named method like `dup` that doesn't duplicate if receiver is mutable https://bugs.ruby-lang.org/issues/18597#change-101925 * Author: danh337 (Dan H) * Status: Open * Priority: Normal ---------------------------------------- This is related to #16295, but focuses only on the `.+@` part. Currently we can use `.dup` in a method chain when we need to mutate a String. However there are cases where the code's context *expects* the String to be mutated. In cases like this, `.dup` always works, but we don't want to duplicate a String that is already mutable. Since `.+@` looks more like an operator, it can be unintuitive in a method chain, so this is asking for a new named method that can be used in its place, instead of always `.dup`. For example: ``` def add_result_text(buffer, new_result) text = "#{new_result.count} #{new_result.input} #{do_fancy_calc(new_result)}\n" buffer.dup_if_immutable << text # ^^^^^^^^^^^^^^^^ new method? end buffer = "" # ...maybe immutable get_lots_of_results.each do |result| buffer = add_result_text(buffer, result) # In case it was dup'ed end ``` ---Files-------------------------------- driver.rb (12.3 KB) driver.rb (12.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112480] [Ruby master Bug#19449] en-us
by Kongpcmail (KAMPANAT THUMWONG) 17 Feb '23

17 Feb '23

Issue #19449 has been reported by Kongpcmail (KAMPANAT THUMWONG). ---------------------------------------- Bug #19449: en-us https://bugs.ruby-lang.org/issues/19449 * Author: Kongpcmail (KAMPANAT THUMWONG) * Status: Open * Priority: Normal * ruby -v: -vomm * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- KAMPANAT THUMWONG ---Files-------------------------------- FFX for Families.en.txt (941 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112476] [Ruby master Bug#19041] Weakref is still alive after major garbage collection
by parker (Parker Finch) 17 Feb '23

17 Feb '23

Issue #19041 has been updated by parker (Parker Finch). File manifest_weakref_issue.rb added Hi @tenderlovemaking! I'm having difficulty interpreting the results of the `ObjectSpace` dump and I'm hoping you can help. I've adjusted the script to print out the address of the underlying object, and then (when the issue manifests) print all lines from `ObjectSpace.dump_all` that match that address. The code is attached, here's some example output: ``` Ruby version: 3.3.0 Iteration: 0 Object address: 0x1051cd788 Inner iterations: 1 Iteration: 1 Object address: 0x105205ae8 Inner iterations: 1 Inner iterations: 2 Inner iterations: 3 {"address":"0x105205ae8", "type":"OBJECT", "shape_id":5, "slot_size":40, "class":"0x1029bfe80", "embedded":true, "ivars":0, "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} {"address":"0x10520da90", "type":"STRING", "shape_id":0, "slot_size":40, "class":"0x1029beda0", "embedded":true, "bytesize":11, "value":"0x105205ae8", "encoding":"UTF-8", "coderange":"7bit", "memsize":40, "flags":{"wb_protected":true, "old":true, "uncollectible":true, "marked":true}} ``` In that example, the underlying object was at `0x105205ae8`. But as far as I can tell, there's nothing else that points at it. (The other object there is the String used to hold that address.) I would have expected that, if nothing was referencing it, it would be collected by GC. One interesting tidbit is that just calling `ObjectSpace.dump_all` prevents the issue from manifesting. Is it possible that something _was_ referencing the object address, then running `dump_all` caused that reference to be removed? ---------------------------------------- Bug #19041: Weakref is still alive after major garbage collection https://bugs.ruby-lang.org/issues/19041#change-101919 * Author: parker (Parker Finch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I am able to get into an infinite loop waiting for garbage collection to take a WeakRef. ### Reproduction Process The following script prints a "0", then a "1", and then hangs forever. I expect it to keep printing numbers. ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) GC.start while obj.weakref_alive? iterations += 1 end ``` ### Ruby Version I have tested this on Ruby 3.1.2, 3.1.0, 3.0.4, 3.0.0, 2.7.6, and 2.7.0 on macOS. All exhibit this behavior. ### Further Investigation #### Sleeping Sleeping before the garbage collection allows the loop to continue. The below exhibits the expected behavior: ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) (sleep(0.5); GC.start) while obj.weakref_alive? iterations += 1 end ``` However, sleeping _after_ the garbage collection still shows the buggy behavior (loop hangs): ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) (GC.start; sleep(0.5)) while obj.weakref_alive? iterations += 1 end ``` #### Running Garbage Collection Multiple Times Explicitly running garbage collection multiple times allows the loop to continue. This has the expected behavior, more numbers continue to be printed: ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) while obj.weakref_alive? GC.start GC.start GC.start end iterations += 1 end ``` However, with certain rubies, running those garbage collection calls in a `times` block prevents even a single iteration from completing. The following prints only "0" with ruby 3.0.4 on macOS, ruby 2.7.6 on macOS, and ruby 3.1.2 on linux (`ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [x86_64-linux]` on a virtual machine). It shows the expected behavior on ruby 3.1.2 on macOS. ``` require "weakref" iterations = 0 loop do print "\r#{iterations}" obj = WeakRef.new(Object.new) 3.times { GC.start } while obj.weakref_alive? iterations += 1 end ``` ---Files-------------------------------- manifest_weakref_issue.rb (1.52 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112474] [Ruby master Bug#19446] Remove `compiler_wd` related warnings in `tool/update-deps`
by eightbitraptor (Matthew Valentine-House) 17 Feb '23

17 Feb '23

Issue #19446 has been reported by eightbitraptor (Matthew Valentine-House). ---------------------------------------- Bug #19446: Remove `compiler_wd` related warnings in `tool/update-deps` https://bugs.ruby-lang.org/issues/19446 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- [Github PR #7331](https://github.com/ruby/ruby/pull/7331) The update deps tool uses intermediary build files to verify dependencies. When these `*.i` files are generated by `gcc` the second line is always of the form ``` # 1 "/home/runner/work/ruby/ruby//" ``` Which `update-deps` attempts to parse out and set as the compiler working directory. It iterates through the intermediary files and sets `compiler_wd` in this loop: ```ruby compiler_wd = nil path_i.each_line {|line| next if /\A\# \d+ "(.*)"/ !~ line dep = $1 next if %r{\A<.*>\z} =~ dep # omit <command-line>, etc. next if /\.e?rb\z/ =~ dep compiler_wd ||= dep files[dep] = true } ``` This will always end up setting `compiler_wd` to the first line in the file, rather than the second, which means the subsequent check for the special gcc compiler dir line will fail, that line will be left in the resulting dependancy lists and manifests later on as warnings. We can see these by looking at any Github Actions Check Dependancies run [like this one](https://github.com/ruby/ruby/actions/runs/4200439119/jobs/7286451096). The warnings look like this ``` warning: file not found: /home/runner/work/ruby/ruby// warning: file not found: /home/runner/work/ruby/ruby// warning: file not found: /home/runner/work/ruby/ruby// ... ( ~350 lines of this) ``` The referenced PR fixes the way `compiler_wd` is set, in order to get rid of the warnings. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112469] [Ruby master Feature#18597] Strings need a named method like `dup` that doesn't duplicate if receiver is mutable
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #18597 has been updated by rubyFeedback (robert heiler). > And it feels like I cannot convince anyone here with any amount of rationale Ultimately you only have to convince matz, so you could ignore what others write. But one reason why there was a reference to real-needs is that the ruby core/dev team said that they focus on real needs (although they may evaluate what is real and what is not ultimately, as well as the cost of addition of methods). My personal opinion is that, usage aside, the .dup_if_immutable feels very clunky. The simplest variant is of course the oldschool ruby: string_object << "More content." I use this pattern, which is a bit verbose: string_object = string_object.dup if string_object.frozen? Then there is that +@ variant. I avoid it, but I guess one reason why it is used is because it is quite short. From a user's perspective, the << usage in oldschool ruby before frozen string is the most convenient, but the primary reason why it was changed was due to speed/efficiency. And other languages such as python have immutable strings too so it's a real concern. ---------------------------------------- Feature #18597: Strings need a named method like `dup` that doesn't duplicate if receiver is mutable https://bugs.ruby-lang.org/issues/18597#change-101914 * Author: danh337 (Dan H) * Status: Open * Priority: Normal ---------------------------------------- This is related to #16295, but focuses only on the `.+@` part. Currently we can use `.dup` in a method chain when we need to mutate a String. However there are cases where the code's context *expects* the String to be mutated. In cases like this, `.dup` always works, but we don't want to duplicate a String that is already mutable. Since `.+@` looks more like an operator, it can be unintuitive in a method chain, so this is asking for a new named method that can be used in its place, instead of always `.dup`. For example: ``` def add_result_text(buffer, new_result) text = "#{new_result.count} #{new_result.input} #{do_fancy_calc(new_result)}\n" buffer.dup_if_immutable << text # ^^^^^^^^^^^^^^^^ new method? end buffer = "" # ...maybe immutable get_lots_of_results.each do |result| buffer = add_result_text(buffer, result) # In case it was dup'ed end ``` ---Files-------------------------------- driver.rb (12.3 KB) driver.rb (12.7 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112468] [Ruby master Feature#18690] Allow `Kernel#then` to take arguments
by rubyFeedback (robert heiler) 17 Feb '23

17 Feb '23

Issue #18690 has been updated by rubyFeedback (robert heiler). I do not have any strong opinions either way, but Benoit wrote: > The last example is just: p.call(honyarara, fugafugafuga, hogehogehoge) > isn't it? And that's a lot more readable IMHO. Versus: honyarara.then(fugafugafuga, hogehogehoge, &p) And I am not sure the .call() is per se more readable. I agree about the trailing &p part; that one looks a bit weird. I guess it is just the block. But ignoring this, if it is merely between .call versus .then, then I think .then may be quite explicit and perhaps "more readable", whatever that means. So I am not sure that .call() is implicitely more readable than .then(). Although, I think one problem is that some ruby authors write code like: if condition then do_something end Or something like that. I never used that style, but some folks used that style in the past. So perhaps it's not quite so readable if we include the totality of the syntax out there. zverok wrote: 3.then.with_object(4).with_object(5).map { |(x, y), z| x + y + z }.first Is this still ruby though? :P ---------------------------------------- Feature #18690: Allow `Kernel#then` to take arguments https://bugs.ruby-lang.org/issues/18690#change-101913 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- `Kernel#then` passes the receiver to the block as its first positional block parameter. ```ruby 1.5.then{|x| Math.atan(x)} ``` I would like to propose to let `then` take arguments, which would be passed to the block as the other block parameters. ```ruby 3.then(4){|x, y| Math.hypot(x, y)} ``` There are two uses. First, to separate bulky or repeated parameters from the routine. Instead of writing: ```ruby honyarara.then{|x| foo(x) bar(fugafugafuga) baz(hogehogehoge) qux(x, fugafugafuga, hogehogehoge) } ``` we can then write: ```ruby honyarara.then(fugafugafuga, hogehogehoge){|x, y, z| foo(x) bar(y) baz(x) qux(x, y, z) } ``` Second, to use a proc with multiple parameters when, for some reason, you do not want to define a method to do it: ```ruby p = ->(x, y, z){ foo(x) bar(y) baz(x) qux(x, y, z) } honyarara.then(fugafugafuga, hogehogehoge, &p) ``` -- https://bugs.ruby-lang.org/

1 0