nobu (Nobuyoshi Nakada) wrote in #note-1: > Why not `ary.transpose[1]&.join`? That avoids the exception but returns `nil` instead of taking advantage of `#join`’s knowledge of the “correct” result for an empty array, i.e. the empty s...tomstuart (Tom Stuart)
One benefit of supplying an initial value to `Enumerable#inject` is that it avoids an annoying edge case when the collection is empty: ``` >> [1, 2, 3].inject(:+) => 6 # good > ... => nil # bad >> [].inject(0, :+) => 0 # good...tomstuart (Tom Stuart)
There’s no reason to prevent RUBYOPT from controlling the backtrace limit. In fact, Matz said [0] he was expecting this to be possible. [0] https://bugs.ruby-lang.org/issues/8661#note-27tomstuart (Tom Stuart)
-1 is a legitimate backtrace limit — in fact, it’s the default — so it should be possible to provide it with the `--backtrace-limit` option.tomstuart (Tom Stuart)
Thank you for accepting! Currently (i.e. on `master` with this patch applied), `--backtrace-limit` in `RUBYOPT` has higher precedence than the command line option: ``` % ruby -v ruby 3.3.0dev (2023-07-13T07:54:27Z backtrace-limit...tomstuart (Tom Stuart)
My main goal is to allow `RUBYOPT` to support `--backtrace-limit`. I am happy to remove the ability to say `--backtrace-limit=-1` from my patch if it’s undesirable, but since `-1` is already a meaningful value for the backtrace limit, i...tomstuart (Tom Stuart)
The `--backtrace-limit` option was added in #8661 but it is not currently supported in the `RUBYOPT` environment variable, which appears to be a mistake. Unlike other long options which are not allowed in `RUBYOPT` (e.g. `--copyright`, `...tomstuart (Tom Stuart)
RubyBugs (A Nonymous) wrote in #note-29: > please consider that making no-args an error makes programming around this API dynamically more complicated I second this request. In the interests of regularity, it should be fine to ask fo...tomstuart (Tom Stuart)
tomstuart (Tom Stuart)07:42 AM Ruby Feature #19830: Allow `Array#transpose` to take an optional size argument