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

[ruby-core:119592] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by Dan0042 (Daniel DeLorme) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by Dan0042 (Daniel DeLorme). > There are certainly backwards compatibility issues from changing `**` from calling `to_hash` to `to_h`. What kind of backwards compatibility issues exactly? My idea was to call #to_hash and fall back to #to_h, that should ensure no backwards incompatibility at all, unless I'm missing something? > Using the unary `**` operator on an object would call the `**@` method, which should return a hash (or raise an exception). That's a very intriguing solution, and very elegant I have to say. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110213 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119591] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by jeremyevans0 (Jeremy Evans) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by jeremyevans0 (Jeremy Evans). There are certainly backwards compatibility issues from changing `**` from calling `to_hash` to `to_h`. I'm sympathetic to the argument that calling `to_h` fits better, as the conversion is explicit and not implicit, but the backwards compatibility costs are probably too high. Maybe in Ruby 4? One possible approach is defining `**@` as an operator method, something like: ```ruby class BasicObject def **@ = to_hash end ``` Using the unary `**` operator on an object would call the `**@` method, which should return a hash (or raise an exception). The method name itself is designed to be similar to `+@` and `-@`, which are called when you use the unary `+` and `-` operators. Users could then change the `**@` method to call `to_h` instead of `to_hash` if they want, and get the explicit conversion behavior (either for all objects, or for specific objects/classes). I proposed `*@` as the method called by the unary `*` operator in #2013, with a working patch, before `**` was introduced for keywords. This was the first issue I filed, back in 2009. It was eventually rejected as there was not much discussion on it, but it was still thought an interesting idea at the time it was rejected. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110212 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119590] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by Dan0042 (Daniel DeLorme) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by Dan0042 (Daniel DeLorme). > I don’t think it can be treated as “explicitly” The `**` is right there in the code, written out caller-side, you can't get more "explicit" than that. > We can apply the same argument to `1 + obj` No we can't; as you know `+` is a method (I guess that would make `**` a "true" operator?) so `1.+(obj)` is similar to `{}.merge(obj)` and falls under implicit conversion (which the method is free to do or not) > What if it _is_ a typo/error? Then I'll fix my stupid mistakes by my own stupid self, thank you very much. > Now, if the user misuses it (by mistake or misunderstanding) and passes some, say, ActiveRecord model as a second parameter, then, with `to_h`, it would be successfully unpacked I think that would be awesome. If I do `other_method(**model)` and that `model` is representable as a hash, passing it as keyword arguments is beautiful. Imagine something like ```ruby ValidOptions = Struct.new(:ssl, :host, :port) opts = ValidOptions.new opts.port = 999 setup_request(**opts) ``` > * problem of things being _unintentionally_ unpacked, considering how many objects have `to_h` method That never happens. I have never ever written code where `foo(**opts)` throws "no implicit conversion of Object into Hash" and then I realize I really meant to use something other than `opts`. > (other than `**(params if condition?)`, which was actually handled). I'll admit that `**nil` covers 90% of the benefits, but the adhoc-ness of it all is a bit frustrating. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110211 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119589] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by zverok (Victor Shepelev) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by zverok (Victor Shepelev). > `{}.merge(**obj)` => obj is explicitly splatted but conversion is done via #to_hash instead of #to_h. It makes no sense, as many many people have commented through the years. I don’t think it can be treated as “explicitly” (invoking hash conversion); it is rather “we apply an operator, which would work with kind-of hash”. We can apply the same argument to `1 + obj`: “you see, I am _explicitly_ summing it with an integer; why is it not converted with `to_int`?” > `**obj` is my intent, not a typo. What if it _is_ a typo/error? Assume this API (frequent in many long-living codebases, which are partially old-style “options hash” and partially new-style “keyword arguments”): ```ruby def process(something, options = {}) # ... other_method(**options) end ``` Now, if the user misuses it (by mistake or misunderstanding) and passes some, say, ActiveRecord model as a second parameter, then, with `to_h`, it would be successfully unpacked, and might go this way (as “keyword arguments” which shouldn’t have been) through several more delegating methods before failing in completely different place—with an extremely hard to debug problem. So, what we are weighting here are: * convenience of unpacking non-hashes into keyword arguments (BTW, what exactly is the use case for this convenience?..), vs. * problem of things being _unintentionally_ unpacked, considering how many objects have `to_h` method; basically failing to “fail early” (where the mistake was made) and instead passing the mistake for who-know-which depth. I honestly fail to see the use case for `to_h` being used with `**` that outweighs the possible problems (other than `**(params if condition?)`, which was actually handled). ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110210 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119588] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by Dan0042 (Daniel DeLorme) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by Dan0042 (Daniel DeLorme). `to_{t}` methods are for explicit type conversion, and `to_{type}` methods are for implicit type conversion. `{}.merge(obj)` => obj is implicitly expected to be Hash, or converted via #to_hash `{}.merge(obj.to_h)` => obj is explicitly converted via #to_h `{}.merge(**obj)` => obj is **explicitly** splatted but conversion is done via #to_hash instead of #to_h. It makes no sense, as many many people have commented through the years. If you're double-splatting an object, of course you'd expect it to be convertible to a Hash. Please assume I'm not an idiot and that `**obj` is my intent, not a typo. Being overly restrictive (only true Hash-like objects can be used!) serves no purpose. Having to do `**obj.to_h` is silly, and adding #to_hash to a class in order to make it splattable is even more silly (possibly dangerous). The fix is easy and backward-compatible; just let double splat convert the object with both #to_hash and #to_h. But instead the "fix" that we got is a weird (although useful) one-off exception for `**nil`. 🙄 ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110209 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119587] [Ruby master Bug#20809] Ripper fails to parse/tokenize nested heredocs within embexpr
by tompng (tomoya ishida) 22 Oct '24

22 Oct '24

Issue #20809 has been reported by tompng (tomoya ishida). ---------------------------------------- Bug #20809: Ripper fails to parse/tokenize nested heredocs within embexpr https://bugs.ruby-lang.org/issues/20809 * Author: tompng (tomoya ishida) * Status: Open * ruby -v: ruby 3.4.0dev (2024-10-22T09:04:30Z master 54065f3b7b) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- In this example, Ripper wrongly concats `"s333\n"` and `"s4444"`. ~~~ruby require 'ripper' code1 = '<<HEREDOC1 s1 #{<<HEREDOC2}s333 s22 HEREDOC2 s4444#{55555} HEREDOC1' p Ripper.tokenize(code1) # => ["<<HEREDOC1", "\n", "s1\n", "\#{", "<<HEREDOC2", "}", "s333\ns4444", "s22\n", "HEREDOC2\n", "\#{", "55555", "}", "\n", "HEREDOC1"] ~~~ In this example, result of `Ripper.sexp` is wrong. `"s333"` disappears. ~~~ruby code2 = '<<HEREDOC1 s1 #{<<HEREDOC2}s333 s22 HEREDOC2 s4444 HEREDOC1' p eval(code2) # => "s1\ns22\ns333\ns4444\n" p Ripper.sexp(code2) # => [:program, [[:string_literal, [:string_content, [:@tstring_content, "s1\n", [2, 0]], [:string_embexpr, [[:string_literal, [:string_content, [:@tstring_content, "s22\n", [4, 0]]]]]], [:@tstring_content, "s4444\n", [6, 0]]]]]] ~~~ -- https://bugs.ruby-lang.org/

1 0

[ruby-core:118932] [Ruby master Bug#20693] Dir.tmpdir should perform a real access check before warning about writability
by kjtsanaktsidis (KJ Tsanaktsidis) 22 Oct '24

22 Oct '24

Issue #20693 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20693: Dir.tmpdir should perform a real access check before warning about writability https://bugs.ruby-lang.org/issues/20693 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- The code in `Dir.tmpdir` attempts to warn the user if their temp directory is deficient for some reason: ```ruby case when !stat.directory? warn "#{name} is not a directory: #{dir}" when !stat.writable? warn "#{name} is not writable: #{dir}" when stat.world_writable? && !stat.sticky? warn "#{name} is world-writable: #{dir}" else break dir end ``` This check for writability is looking at the user/group/world access bits on the stat output, and determining if the user running Ruby is allowed to write to the temp directory based on that. However, modern operating systems contain other mechanisms apart from the user/group/world bits which can grant access to a directory that would otherwise be denied, or vice versa. Things like: * Posix ACL's * Linux's capabilities like CAP_DAC_OVERRIDE * Linux Security Modules like SELinux or AppArmor * Syscall filters like Linux's seccomp * Granular capability systems like FreeBSD's Capsicum * OpenBSD's pledge and unveil * Windows too has a rich ACL system for controlling filesystem access To address this, we should call `File.writable?` instead of `stat.writable?`, which asks the system whether the file is writable using the `euidaccess()` function if available. On Linux/glibc, at least, this will issue an `access(2)` syscall, and the Kernel can take all of the above into account. n.b. if Ruby is running as suid, then glibc currently will NOT ask the kernel to perform the access check in `euidaccess()`, and instead does a similar thing to what `Stat#writable?` does (https://github.com/bminor/glibc/blob/7f04bb4e49413bd57ac3215f3480b09ae71319…) This is because of the relatively new `faccessat2(2)` syscall is required to do this properly, and there is some ecosystem issues with leveraging this by default (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1900021) Since running Ruby as suid is probably a very bad idea anyway, and the glibc implementation isn't any worse than the `Stat#writable?` one, this seems OK though. -- https://bugs.ruby-lang.org/

4 8

[ruby-core:119585] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by zverok (Victor Shepelev) 22 Oct '24

22 Oct '24

Issue #15381 has been updated by zverok (Victor Shepelev). I believe that the general agreement is that short `to_{t}` methods (`to_s`, `to_i`, `to_h`, `to_a`) have a semantics of “have some {type} representation/can be converted to {type}", while long `to_{type}` ones have a meaning of “are kind-of {type}”. Mostly (though not exclusively), `to_{t}` is used via explicit calls, while `to_{type}` converts the object implicitly on various operators. Now, I believe that using `to_h` (an explicit conversion method) implicitly on `**` would lead to a lot of unintended consequences. Things that typically have `to_h` but are not intended as “option hashes” are, for example: * every Enumerable * most of model-like things (from ActiveRecord to mere Struct) Having them suddenly unpack when nobody intended that (say, typoing `**array` instead of `*array`; or by mistake passing model instance instead of some `options` to a place where it would be handled with `**options`) might lead to very confusing error messages at the very least, and mysterious, hard to debug behavior in worse cases. PS: I actually believe that `*` invoking `to_a` and not `to_ary` brings more bad than good (things like `Time` or `Struct` can be unpacked when, again, nobody has intended it; it also breaks the mental model of explicit/implicit conversion methods). However, it is obviously too late to fix that. ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110204 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119581] [Ruby master Feature#15381] Let double splat call `to_h` implicitly
by sanjioh (Fabio Sangiovanni) 21 Oct '24

21 Oct '24

Issue #15381 has been updated by sanjioh (Fabio Sangiovanni). Eregon (Benoit Daloze) wrote in #note-4: > Should `**` call `to_h` rather than `to_hash`, similar to `*` calling `to_a` and not `to_ary`? Hi, I’m learning Ruby and the fact that `**` calls `to_hash` rather than `to_h` surprised me; I would expect it to be consistent to `*` calling `to_a`. I suppose that changing this behavior would break to much code, though. A pointer to the decision making process that lead to using `to_hash` would be helpful nonetheless. Thanks! ---------------------------------------- Feature #15381: Let double splat call `to_h` implicitly https://bugs.ruby-lang.org/issues/15381#change-110200 * Author: sawa (Tsuyoshi Sawada) * Status: Open ---------------------------------------- The single splat calls `to_a` implicitly on the object (if it is not an array already) so that, for example, we have the convenience of writing conditions in an array literal: ```ruby a = [ *(:foo if some_condition), *(:bar if another_condition), ] ``` And the ampersand implicitly calls `to_proc` on the object (if it is not a proc already) so that we can substitute a block with an ampersand followed by a symbol: ```ruby some_method(&:some_method_name) ``` Unlike the single splat and ampersand, the double splat does not seem to implicitly call a corresponding method. I propose that the double splat should call `to_h` implicitly on the object if it not already a Hash so that we can, for example, write a condition in a hash literal as follows: ```ruby h = { **({a: 1} if some_condition), **({b: 2) if another_condition), } ``` There may be some other benefits of this feature that I have not noticed yet. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:119561] [Ruby master Misc#20806] Redmine ML forwarding seems to be broken (likely since Oct 15)
by vo.x (Vit Ondruch) 21 Oct '24

21 Oct '24

Issue #20806 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Misc #20806: Redmine ML forwarding seems to be broken (likely since Oct 15) https://bugs.ruby-lang.org/issues/20806 * Author: vo.x (Vit Ondruch) * Status: Open ---------------------------------------- I am subscribed to ruby-core ML and it seems that Redmine have not forwarded any notification there since ~Oct 15. Could somebody PTAL? -- https://bugs.ruby-lang.org/

2 3