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

[ruby-core:111216] [Ruby master Feature#18980] Re-reconsider numbered parameters: `it` as a default block parameter
by maedi (Maedi Prichard) 06 Dec '22

06 Dec '22

Issue #18980 has been updated by maedi (Maedi Prichard). I see that `$.` is already a <a href="https://docs.ruby-lang.org/en/2.4.0/globals_rdoc.html">pre-defined variable</a> which would make `$.method_name` difficult to parse. Then `_$` looks a little bit too close to the pre-defined variable `$_`. Though I still like `_@`. Can anyone think of a solution? Anything is better than `_1`. I personally like `@` and `it` and `this` and `that` but there always seems to be some conflict with existing variables and methods. What about `$this` or `$it`? If someone somewhere ever named their global variable `$it` and used it in a block then I'm sure they would forgive us, if this unlikely situation ever happened at all. ```ruby [1, 2, 3].each { puts $it } ``` ---------------------------------------- Feature #18980: Re-reconsider numbered parameters: `it` as a default block parameter https://bugs.ruby-lang.org/issues/18980#change-100507 * Author: k0kubun (Takashi Kokubun) * Status: Open * Priority: Normal ---------------------------------------- ## Problem Numbered parameters (`_1`, `_2`, ...) look like unused local variables and I don't feel motivated to use them, even though I need this feature very often and always come up with `_1`. ```rb [1, 2, 3].each { puts _1 } ``` I have barely used it in the last 2~3 years because it looks like a compromised syntax. I even hesitate to use it on IRB. ### Why I don't use `_1` I'm not clever enough to remember the order of parameters. Therefore, when a block has multiple parameters, I'd always want to name those parameters because which is `_1` or `_2` is not immediately obvious. Thus I would use this feature only when a block takes a single argument, which is actually pretty common. If I use `_1`, it feels like there might be a second argument, and you might waste time to think about `_2`, even if `_2` doesn't exist, which is a cognitive overhead. If you use `it`, it kinda implies there's only a single argument, so you don't need to spend time remembering whether `_2` exists or not. It is important for me that there's no number in `it`. ## Proposal Hoping to introduce `it` as an alternative to `_1` later, experiment with warning `#it` method calls without any arguments or blocks. If nobody sees serious problems after some warning period, we'll implement `it` as follows: ### Specification ```rb [1, 2, 3].each { puts it } ``` `it`s behavior should be as close to `_1` as possible. `it` should treat array arguments in the same way as `_1`. `it` doesn't work in a block when an ordinary parameter is defined. `it` is implemented as a special case of `getlocal` insn, not a method. `it` without an argument is considered `_1` or a normal local variable if defined. `it` is considered a method call only when it has any positional/keyword/block arguments. ## Past discussions * [Feature #4475] default variable name for parameter: Proposed `it`, and merged as `@1`. * 2019/03/13: [DevelopersMeeting20190311Japan](https://docs.google.com/document/d/e/2PACX-… * 2019/04/17: [DevelopersMeeting20190417Japan](https://docs.google.com/document/d/1hw6Xca8… * 2019/04/20: [Ruby Committers vs the World](https://youtu.be/5eAXAUTtNYU?t=3118) * [Feature #15723] Reconsider numbered parameters: Renamed `@1` to `_1`. * 2019/08/29: [DevelopersMeeting20190829Japan](https://docs.google.com/document/d/1XypDO1c… * [Feature #15897] `it` as a default block parameter: Proposed `it`, and got closed because `_1` was merged. ### Compatibility `it` has not necessarily been rejected by Matz; he just said [it's difficult to keep compatibility](https://bugs.ruby-lang.org/issues/4475#note-6) and [`it` or `this` _could_ break existing code](https://bugs.ruby-lang.org/issues/15723#note-2). It feels like everybody thinks `it` is the most beautiful option but is not sure if `it` breaks compatibility. But, in reality, does `it`? The following cases have been discussed: * `it` method, most famously in RSpec: You almost always pass a positional and/or block argument to RSpec's `it`, so the conflict is avoided with my proposal. You virtually never use a completely naked `it` ([comment](https://bugs.ruby-lang.org/issues/15897#note-29)) * `it` local variable: With the specification in my proposal, the existing code can continue to work if we consider `it` as a local variable when defined. With the specification in my proposal, existing code seems to break if and only if you call a method `#it` without an argument. But it seems pretty rare (reminder: a block given to an RSpec test case is also an argument). It almost feels like people are too afraid of compatibility problems that barely exist or have not really thought about options to address them. Also, you could always experiment with just showing warnings, which doesn't break any compatibility. Even if it takes 2~3 years of a warning period, I'd be happy to use that in 3 years. ### Confusion We should separately discuss incompatible cases and "works but confusing" cases. Potential confusion points: * RSpec's `it "tests something" do ... end` vs `it` inside the `do ... end` * `it` could be a local variable or `_1`, depending on the situation My two cents: You'd rarely need to write `it` directly under RSpec's `it` block, and you would just name a block argument for that case. In a nested block under a test case, I don't think you'd feel `it` is RSpec's. When you use a local variable `it = 1`, you'd use the local variable in a very small scope or few lines because otherwise, it'd be very hard to figure out what the local variable has anyway. So you'd likely see the assignment `it = 1` near the use of the local variable and you could easily notice `it` is not `_1`. If not, such code would be confusing and fragile even without this feature. The same applies when `it` is a method/block argument. I believe it wouldn't be as confusing as some people think, and you can always choose to not use `it` in places where `it` is confusing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111215] [Ruby master Bug#19007] Unicode tables differences from Unicode.org 14.0 data
by duerst 06 Dec '22

06 Dec '22

Issue #19007 has been updated by duerst (Martin Dürst). The wrong properties were fixed for version 14.0.0 with commit e31d645. This issue should stay open until we are sure what caused the wrong properties in the first place. ---------------------------------------- Bug #19007: Unicode tables differences from Unicode.org 14.0 data https://bugs.ruby-lang.org/issues/19007#change-100505 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Assignee: duerst (Martin Dürst) * Target version: 3.2 * ruby -v: 3.2.0 6898984f1cd * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED ---------------------------------------- I found the header in Unicode Emoji 14.0 data files had changed slightly (and again at 15.0), but `enc/unicode/case-folding.rb` didn't follow it. Then I fixed it and rebuilt the headers under `enc/unicode/14.0.0`, `name2ctype.h` had diffences from the master, as bellow. `CR_Lower`, `CR_Cased` and `CR_Other_Lowercase` just seem misses in the previous operation, and no problems. But U+11720..U+11721 in `CR_Grapheme_Cluster_Break_SpacingMark` is absent in the original data of the Unicode.org. According to @naruse's investigation, it was removed at the commit [Update to Unicode 14.0.0], while U+11720 is still SpacingMark in the latest https://www.unicode.org/reports/tr29/. [Update to Unicode 14.0.0]: https://github.com/latex3/unicode-data/commit/5570040ac8a30e2c2ca4912d415ec… ```diff diff --git a/enc/unicode/14.0.0/name2ctype.h b/enc/unicode/14.0.0/name2ctype.h index 99a3eeca190..f49e5cd7273 100644 --- a/enc/unicode/14.0.0/name2ctype.h +++ b/enc/unicode/14.0.0/name2ctype.h @@ -1565,7 +1565,7 @@ static const OnigCodePoint CR_Graph[] = { /* 'Lower': [[:Lower:]] */ static const OnigCodePoint CR_Lower[] = { - 664, + 668, 0x0061, 0x007a, 0x00aa, 0x00aa, 0x00b5, 0x00b5, @@ -2196,6 +2196,10 @@ static const OnigCodePoint CR_Lower[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10cc0, 0x10cf2, 0x118c0, 0x118df, 0x16e60, 0x16e7f, @@ -12651,7 +12655,7 @@ static const OnigCodePoint CR_Math[] = { /* 'Cased': Derived Property */ static const OnigCodePoint CR_Cased[] = { - 151, + 155, 0x0041, 0x005a, 0x0061, 0x007a, 0x00aa, 0x00aa, @@ -12763,6 +12767,10 @@ static const OnigCodePoint CR_Cased[] = { 0x105a3, 0x105b1, 0x105b3, 0x105b9, 0x105bb, 0x105bc, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, 0x10c80, 0x10cb2, 0x10cc0, 0x10cf2, 0x118a0, 0x118df, @@ -22615,7 +22623,7 @@ static const OnigCodePoint CR_Extender[] = { /* 'Other_Lowercase': Binary Property */ static const OnigCodePoint CR_Other_Lowercase[] = { - 20, + 24, 0x00aa, 0x00aa, 0x00ba, 0x00ba, 0x02b0, 0x02b8, @@ -22636,6 +22644,10 @@ static const OnigCodePoint CR_Other_Lowercase[] = { 0xa770, 0xa770, 0xa7f8, 0xa7f9, 0xab5c, 0xab5f, + 0x10780, 0x10780, + 0x10783, 0x10785, + 0x10787, 0x107b0, + 0x107b2, 0x107ba, }; /* CR_Other_Lowercase */ /* 'Other_Uppercase': Binary Property */ @@ -37049,7 +37061,7 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_Extend[] = { /* 'Grapheme_Cluster_Break_SpacingMark': Grapheme_Cluster_Break=SpacingMark */ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { - 161, + 160, 0x0903, 0x0903, 0x093b, 0x093b, 0x093e, 0x0940, @@ -37183,7 +37195,6 @@ static const OnigCodePoint CR_Grapheme_Cluster_Break_SpacingMark[] = { 0x116ac, 0x116ac, 0x116ae, 0x116af, 0x116b6, 0x116b6, - 0x11720, 0x11721, 0x11726, 0x11726, 0x1182c, 0x1182e, 0x11838, 0x11838, ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111214] [Ruby master Bug#19115] RubyGems fails to detect OpenSSL in --with-static-linked-ext builds
by alanwu (Alan Wu) 05 Dec '22

05 Dec '22

Issue #19115 has been updated by alanwu (Alan Wu). thomthom (Thomas Thomassen) wrote in #note-8: > Will this patch be pack-ported to the 3.1 branch? It's up to the branch maintainer, @nagachika, to decide. ---------------------------------------- Bug #19115: RubyGems fails to detect OpenSSL in --with-static-linked-ext builds https://bugs.ruby-lang.org/issues/19115#change-100504 * Author: thomthom (Thomas Thomassen) * Status: Closed * Priority: Normal * ruby -v: 3.1.2, 3.2.0dev * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Related discussion: https://bugs.ruby-lang.org/issues/18876 We are seeing OpenSSL failing to autoload with the Ruby build we've been using. (We first observed this when using `Gem.install` that relies on autoload of OpenSSL). Our last working build was Ruby 2.7.2 with similar config. This causes RubyGems' `HAVE_OPENSSL` constant to be incorrectly initialized, and subsequent calls to `Gem.install` fails. There might be other scenarios that fail as a result of that, but we've not managed to identified that. ``` module Gem HAVE_OPENSSL = defined? OpenSSL::SSL # :nodoc: ``` Our Ruby 3.1.2 config: ``` '--prefix=/Users/user/.conan/data/ruby/3.1.2/sketchup/stable/build/bd95825b99dcb274d0e577fbdc953653a9ea0fb9' '--with-openssl-dir=/Users/user/.conan/data/openssl/1.1.1q/sketchup/stable/package/93ae0b0e7eebe0611c04d3e0d9bbf49fbce92332' '--with-libyaml-dir=/Users/user/.conan/data/libyaml/0.2.5/sketchup/stable/package/a56a950abed2e10dbdc26845400f0a034d97c454' '--disable-install-doc' '--disable-install-rdoc' '--enable-shared' '--enable-load-relative' '--with-static-linked-ext' '--without-debug' '--without-gdbm' '--without-gettext' '--without-irb' '--without-mkmf' '--without-rdoc' '--without-readline' '--without-tk' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libexecdir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--datarootdir=${prefix}/share' 'cflags=-mmacosx-version-min=10.14 -fdeclspec' 'cxxflags=-mmacosx-version-min=10.14 -fdeclspec' 'LDFLAGS=-mmacosx-version-min=10.14 -fdeclspec' ``` We also tested with latest build from master (November 8th 2022): ``` ./ruby -ve 'p RbConfig::CONFIG["configure_args"]' ruby 3.2.0dev (2022-11-07T19:35:21Z master b14f133054) [x86_64-darwin20] " '--prefix=/Users/vmehta/ruby/ruby-master/' '--with-openssl-dir=/Users/vmehta/.conan/data/openssl/1.1.1q/sketchup/stable/package/f2d937af1fa19d5fc4095849a65d1927e9e75ae7/' '--with-libyaml-dir=/Users/vmehta/.conan/data/libyaml/0.2.5/sketchup/stable/package/3fc084e254210603a5c5aece184b2d45e2509b30' '--disable-install-doc' '--disable-install-rdoc' '--enable-shared' '--enable-load-relative' '--with-static-linked-ext' '--without-debug' '--without-gdbm' '--without-gettext' '--without-irb' '--without-mkmf' '--without-rdoc' '--without-readline' '--without-tk'" ``` Using an RVM of Ruby 3.1.2 this appear to work as expected. But using out configuration, that we've used for the Ruby 2.x versions are now failing. We haven't been able to figure out the reason for this. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111213] [Ruby master Feature#16122] Data: simple immutable value object
by zverok (Victor Shepelev) 05 Dec '22

05 Dec '22

Issue #16122 has been updated by zverok (Victor Shepelev). @ston1x I understand where you are coming from (make the declaration more homogenous for the sake of IDE's convenience), and I don't think that the goal is meaningless, but in this case, it will lead to severe complication of semantics/implementation: what's the state of the object between `Ticket < Data` and `attr`? What if `attr` never declared? What if it used several times? What if it used again in the descendant of `Ticket`? This kind of complication doesn't seem worth the gain, for me. It is up to IDE to handle `Data`, it seems (as far as I know, say, YARD documentation system has a handling for `Struct` descendants, and it isn't impossible for other tools, too). Especially considering that a lot of `Data` usage would probably be just short one-line declarations and ideally, IDE that wants to autocomplete available attributes should understand them anyway, so... ---------------------------------------- Feature #16122: Data: simple immutable value object https://bugs.ruby-lang.org/issues/16122#change-100503 * Author: zverok (Victor Shepelev) * Status: Closed * Priority: Normal * Assignee: zverok (Victor Shepelev) ---------------------------------------- ## Intro (original theoretical part of the proposal) **Value Object** is a useful concept, introduced by Martin Fowler ([his post](https://martinfowler.com/bliki/ValueObject.html), [Wikipedia Entry](https://en.wikipedia.org/wiki/Value_object)) with the following properties (simplifying the idea): * representing some relatively simple data; * immutable; * compared by type & value; * nicely represented. Value objects are super-useful especially for defining APIs, their input/return values. Recently, there were some movement towards using more immutability-friendly approach in Ruby programming, leading to creating several discussions/libraries with value objects. For example, [Tom Dalling's gem](https://github.com/tomdalling/value_semantics), [Good Ruby Value object convention](https://github.com/zverok/good-value-object) (disclaimer: the latter is maintained by yours truly). I propose to introduce **native value objects** to Ruby as a core class. **Why not a gem?** * I believe that concept is that simple, that nobody *will even try* to use a gem for representing it with, unless the framework/library used already provides one. * Potentially, a lot of standard library (and probably even core) APIs could benefit from the concept. **Why `Struct` is not enough** Core `Struct` class is "somewhat alike" value-object, and frequently used instead of one: it is compared by value and consists of simple attributes. On the other hand, `Struct` is: * mutable; * collection-alike (defines `to_a` and is `Enumerable`); * dictionary-alike (has `[]` and `.values` methods). The above traits somehow erodes the semantics, making code less clear, especially when duck-typing is used. For example, this code snippet shows why `to_a` is problematic: ```ruby Result = Struct.new(:success, :content) # Now, imagine that other code assumes `data` could be either Result, or [Result, Result, Result] # So, ... data = Result.new(true, 'it is awesome') Array(data) # => expected [Result(true, 'it is awesome')], got [true, 'it is awesome'] # or... def foo(arg1, arg2 = nil) p arg1, arg2 end foo(*data) # => expected [Result(true, 'it is awesome'), nil], got [true, 'it is awesome'] ``` Having `[]` and `each` defined on something that is thought as "just value" can also lead to subtle bugs, when some method checks "if the received argument is collection-alike", and value object's author doesn't thought of it as a collection. ## `Data` class: consensus proposal/implementation, Sep 2022 * Name: `Data` * PR: https://github.com/ruby/ruby/pull/6353 * Example docs rendering: https://zverok.space/ruby-rdoc/Data.html * Full API: * `Data::define` creates a new Data class; accepts only symbols (no `keyword_init:`, no "first argument is the class name" like the `Struct` had) * `<data_class>::members`: list of member names * `<data_class>::new`: accepts either keyword or positional arguments (but not mix); converts all of the to keyword args; raises `ArgumentError` if there are **too many positional arguments** * `#initialize`: accepts only keyword arguments; the default implementation raises `ArgumentError` on missing or extra arguments; it is easy to redefine `initialize` to provide defaults or handle extra args. * `#==` * `#eql?` * `#inspect`/`#to_s` (same representation) * `#deconstruct` * `#deconstruct_keys` * `#hash` * `#members` * `#to_h` ## Historical original proposal * Class name: `Struct::Value`: lot of Rubyists are used to have `Struct` as a quick "something-like-value" drop-in, so alternative, more strict implementation, being part of `Struct` API, will be quite discoverable; *alternative: just `Value`* * Class API is copying `Struct`s one (most of the time -- even reuses the implementation), with the following exceptions *(note: the immutability is **not** the only difference)*: * Not `Enumerable`; * Immutable; * Doesn't think of itself as "almost hash" (doesn't have `to_a`, `values` and `[]` methods); * Can have empty members list (fun fact: `Struct.new('Foo')` creating member-less `Struct::Foo`, is allowed, but `Struct.new()` is not) to allow usage patterns like: ```ruby class MyService Success = Struct::Value.new(:results) NotFound = Struct::Value.new end ``` `NotFound` here, unlike, say, `Object.new.freeze` (another pattern for creating "empty typed value object"), has nice inspect `#<value NotFound>`, and created consistently with the `Success`, making the code more readable. And if it will evolve to have some attributes, the code change would be easy. **Patch is provided** [Sample rendered RDoc documentation](https://zverok.github.io/ruby-rdoc/Struct-Value.html) ---Files-------------------------------- struct_value.patch (18.6 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111210] [Ruby master Bug#19184] create a Range with String subclass presents a weird behavior
by clavius_tales (Clavius Tales Rocha Moreira) 05 Dec '22

05 Dec '22

Issue #19184 has been reported by clavius_tales (Clavius Tales Rocha Moreira). ---------------------------------------- Bug #19184: create a Range with String subclass presents a weird behavior https://bugs.ruby-lang.org/issues/19184 * Author: clavius_tales (Clavius Tales Rocha Moreira) * Status: Open * Priority: Normal * ruby -v: 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- ``` ruby class CalendarMonth < String def succ self.class.new( if december? "#{year + 1}-01" else "#{year}-#{(month + 1).to_s.rjust(2, '0')}" end ) end private def december? month == 12 end def month self[-2..].to_i end def year self[0..3].to_i end end (CalendarMonth.new('2021-11')..CalendarMonth.new('2022-02')).to_a ``` Running the script above in Ruby 2.7.5, we get: ``` ruby ["2021-11", "2021-12", "2022-01", "2022-02"] ``` Running the same script in Ruby 3.1.3: ```ruby ["2021-11", "2021-12", "2021-13", "2021-14", "2021-15", "2021-16", "2021-17", "2021-18", "2021-19", "2021-20", "2021-21", "2021-22", "2021-23", "2021-24", "2021-25", "2021-26", "2021-27", "2021-28", "2021-29", "2021-30", "2021-31", "2021-32", "2021-33", "2021-34", "2021-35", "2021-36", "2021-37", "2021-38", "2021-39", "2021-40", "2021-41", "2021-42", "2021-43", "2021-44", "2021-45", "2021-46", "2021-47", "2021-48", "2021-49", "2021-50", "2021-51", "2021-52", "2021-53", "2021-54", "2021-55", "2021-56", "2021-57", "2021-58", "2021-59", "2021-60", "2021-61", "2021-62", "2021-63", "2021-64", "2021-65", "2021-66", "2021-67", "2021-68", "2021-69", "2021-70", "2021-71", "2021-72", "2021-73", "2021-74", "2021-75", "2021-76", "2021-77", "2021-78", "2021-79", "2021-80", "2021-81", "2021-82", "2021-83", "2021-84", "2021-85", "2021-86", "2021-87", "2021-88", "2021-89", "2021-90", "2021-91", "2021-92", "2021-93", "2021-94", "2021-95", "2021-96", "2021-97", "2021-98", "2021-99", "2022-00", "2022-01", "2022-02"] ``` I know it's not a good modeling inherit from String class, but... -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111209] [Ruby master Bug#19115] RubyGems fails to detect OpenSSL in --with-static-linked-ext builds
by thomthom (Thomas Thomassen) 05 Dec '22

05 Dec '22

Issue #19115 has been updated by thomthom (Thomas Thomassen). Will this patch be pack-ported to the 3.1 branch? ---------------------------------------- Bug #19115: RubyGems fails to detect OpenSSL in --with-static-linked-ext builds https://bugs.ruby-lang.org/issues/19115#change-100500 * Author: thomthom (Thomas Thomassen) * Status: Closed * Priority: Normal * ruby -v: 3.1.2, 3.2.0dev * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Related discussion: https://bugs.ruby-lang.org/issues/18876 We are seeing OpenSSL failing to autoload with the Ruby build we've been using. (We first observed this when using `Gem.install` that relies on autoload of OpenSSL). Our last working build was Ruby 2.7.2 with similar config. This causes RubyGems' `HAVE_OPENSSL` constant to be incorrectly initialized, and subsequent calls to `Gem.install` fails. There might be other scenarios that fail as a result of that, but we've not managed to identified that. ``` module Gem HAVE_OPENSSL = defined? OpenSSL::SSL # :nodoc: ``` Our Ruby 3.1.2 config: ``` '--prefix=/Users/user/.conan/data/ruby/3.1.2/sketchup/stable/build/bd95825b99dcb274d0e577fbdc953653a9ea0fb9' '--with-openssl-dir=/Users/user/.conan/data/openssl/1.1.1q/sketchup/stable/package/93ae0b0e7eebe0611c04d3e0d9bbf49fbce92332' '--with-libyaml-dir=/Users/user/.conan/data/libyaml/0.2.5/sketchup/stable/package/a56a950abed2e10dbdc26845400f0a034d97c454' '--disable-install-doc' '--disable-install-rdoc' '--enable-shared' '--enable-load-relative' '--with-static-linked-ext' '--without-debug' '--without-gdbm' '--without-gettext' '--without-irb' '--without-mkmf' '--without-rdoc' '--without-readline' '--without-tk' '--bindir=${prefix}/bin' '--sbindir=${prefix}/bin' '--libexecdir=${prefix}/bin' '--libdir=${prefix}/lib' '--includedir=${prefix}/include' '--oldincludedir=${prefix}/include' '--datarootdir=${prefix}/share' 'cflags=-mmacosx-version-min=10.14 -fdeclspec' 'cxxflags=-mmacosx-version-min=10.14 -fdeclspec' 'LDFLAGS=-mmacosx-version-min=10.14 -fdeclspec' ``` We also tested with latest build from master (November 8th 2022): ``` ./ruby -ve 'p RbConfig::CONFIG["configure_args"]' ruby 3.2.0dev (2022-11-07T19:35:21Z master b14f133054) [x86_64-darwin20] " '--prefix=/Users/vmehta/ruby/ruby-master/' '--with-openssl-dir=/Users/vmehta/.conan/data/openssl/1.1.1q/sketchup/stable/package/f2d937af1fa19d5fc4095849a65d1927e9e75ae7/' '--with-libyaml-dir=/Users/vmehta/.conan/data/libyaml/0.2.5/sketchup/stable/package/3fc084e254210603a5c5aece184b2d45e2509b30' '--disable-install-doc' '--disable-install-rdoc' '--enable-shared' '--enable-load-relative' '--with-static-linked-ext' '--without-debug' '--without-gdbm' '--without-gettext' '--without-irb' '--without-mkmf' '--without-rdoc' '--without-readline' '--without-tk'" ``` Using an RVM of Ruby 3.1.2 this appear to work as expected. But using out configuration, that we've used for the Ruby 2.x versions are now failing. We haven't been able to figure out the reason for this. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111208] [Ruby master Feature#19183] Add bin/goruby, bin/ruby, and lib/libruby.so.3.2.0 (or similar) to .gitignore
by duerst 05 Dec '22

05 Dec '22

Issue #19183 has been reported by duerst (Martin Dürst). ---------------------------------------- Feature #19183: Add bin/goruby, bin/ruby, and lib/libruby.so.3.2.0 (or similar) to .gitignore https://bugs.ruby-lang.org/issues/19183 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal ---------------------------------------- When I compile ruby, and then use `git status`, the files `bin/goruby`, `bin/ruby`, and `lib/libruby.so.3.2.0` (or similar) always show up as untracked files. I think they should be added to .gitignore. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111181] [Ruby master Feature#19177] optional offset for Array#index
by Dan0042 (Daniel DeLorme) 05 Dec '22

05 Dec '22

Issue #19177 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #19177: optional offset for Array#index https://bugs.ruby-lang.org/issues/19177 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- String#index allows an optional offset: ```ruby "the quick brown fox jumps over the lazy dog".index("the") #=> 0 "the quick brown fox jumps over the lazy dog".index("the",1) #=> 31 ``` I was a bit surprised that Array doesn't support this and I feel it would be a very natural addition: ```ruby %w[the quick brown fox jumps over the lazy dog].index("the") #=> 0 %w[the quick brown fox jumps over the lazy dog].index("the",1) #=> 6 instead of ArgumentError ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111206] [Ruby master Feature#16122] Data: simple immutable value object
by matz (Yukihiro Matsumoto) 05 Dec '22

05 Dec '22

Issue #16122 has been updated by matz (Yukihiro Matsumoto). I propose a little bit different approach: ```ruby Ticket = Data.define(:event_id, :user_id,:start_at) do # And other methods defined below def validate puts "Validated!" end end ``` This is much consistent and work now without any enhancement. Matz. ---------------------------------------- Feature #16122: Data: simple immutable value object https://bugs.ruby-lang.org/issues/16122#change-100496 * Author: zverok (Victor Shepelev) * Status: Closed * Priority: Normal * Assignee: zverok (Victor Shepelev) ---------------------------------------- ## Intro (original theoretical part of the proposal) **Value Object** is a useful concept, introduced by Martin Fowler ([his post](https://martinfowler.com/bliki/ValueObject.html), [Wikipedia Entry](https://en.wikipedia.org/wiki/Value_object)) with the following properties (simplifying the idea): * representing some relatively simple data; * immutable; * compared by type & value; * nicely represented. Value objects are super-useful especially for defining APIs, their input/return values. Recently, there were some movement towards using more immutability-friendly approach in Ruby programming, leading to creating several discussions/libraries with value objects. For example, [Tom Dalling's gem](https://github.com/tomdalling/value_semantics), [Good Ruby Value object convention](https://github.com/zverok/good-value-object) (disclaimer: the latter is maintained by yours truly). I propose to introduce **native value objects** to Ruby as a core class. **Why not a gem?** * I believe that concept is that simple, that nobody *will even try* to use a gem for representing it with, unless the framework/library used already provides one. * Potentially, a lot of standard library (and probably even core) APIs could benefit from the concept. **Why `Struct` is not enough** Core `Struct` class is "somewhat alike" value-object, and frequently used instead of one: it is compared by value and consists of simple attributes. On the other hand, `Struct` is: * mutable; * collection-alike (defines `to_a` and is `Enumerable`); * dictionary-alike (has `[]` and `.values` methods). The above traits somehow erodes the semantics, making code less clear, especially when duck-typing is used. For example, this code snippet shows why `to_a` is problematic: ```ruby Result = Struct.new(:success, :content) # Now, imagine that other code assumes `data` could be either Result, or [Result, Result, Result] # So, ... data = Result.new(true, 'it is awesome') Array(data) # => expected [Result(true, 'it is awesome')], got [true, 'it is awesome'] # or... def foo(arg1, arg2 = nil) p arg1, arg2 end foo(*data) # => expected [Result(true, 'it is awesome'), nil], got [true, 'it is awesome'] ``` Having `[]` and `each` defined on something that is thought as "just value" can also lead to subtle bugs, when some method checks "if the received argument is collection-alike", and value object's author doesn't thought of it as a collection. ## `Data` class: consensus proposal/implementation, Sep 2022 * Name: `Data` * PR: https://github.com/ruby/ruby/pull/6353 * Example docs rendering: https://zverok.space/ruby-rdoc/Data.html * Full API: * `Data::define` creates a new Data class; accepts only symbols (no `keyword_init:`, no "first argument is the class name" like the `Struct` had) * `<data_class>::members`: list of member names * `<data_class>::new`: accepts either keyword or positional arguments (but not mix); converts all of the to keyword args; raises `ArgumentError` if there are **too many positional arguments** * `#initialize`: accepts only keyword arguments; the default implementation raises `ArgumentError` on missing or extra arguments; it is easy to redefine `initialize` to provide defaults or handle extra args. * `#==` * `#eql?` * `#inspect`/`#to_s` (same representation) * `#deconstruct` * `#deconstruct_keys` * `#hash` * `#members` * `#to_h` ## Historical original proposal * Class name: `Struct::Value`: lot of Rubyists are used to have `Struct` as a quick "something-like-value" drop-in, so alternative, more strict implementation, being part of `Struct` API, will be quite discoverable; *alternative: just `Value`* * Class API is copying `Struct`s one (most of the time -- even reuses the implementation), with the following exceptions *(note: the immutability is **not** the only difference)*: * Not `Enumerable`; * Immutable; * Doesn't think of itself as "almost hash" (doesn't have `to_a`, `values` and `[]` methods); * Can have empty members list (fun fact: `Struct.new('Foo')` creating member-less `Struct::Foo`, is allowed, but `Struct.new()` is not) to allow usage patterns like: ```ruby class MyService Success = Struct::Value.new(:results) NotFound = Struct::Value.new end ``` `NotFound` here, unlike, say, `Object.new.freeze` (another pattern for creating "empty typed value object"), has nice inspect `#<value NotFound>`, and created consistently with the `Success`, making the code more readable. And if it will evolve to have some attributes, the code change would be easy. **Patch is provided** [Sample rendered RDoc documentation](https://zverok.github.io/ruby-rdoc/Struct-Value.html) ---Files-------------------------------- struct_value.patch (18.6 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111205] [Ruby master Bug#19182] ALWAYS_UPDATE_UNICODE=yes downloads all the Unicode files twice when executing make
by duerst 05 Dec '22

05 Dec '22

Issue #19182 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #19182: ALWAYS_UPDATE_UNICODE=yes downloads all the Unicode files twice when executing make https://bugs.ruby-lang.org/issues/19182 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 3.2.0dev (2022-12-04T20:23:09Z master d90835aeb5) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- `make` downloads all the Unicode files twice when ALWAYS_UPDATE_UNICODE is set to yes. One download is for miniruby, the second is for ruby. This shouldn't be necessary. I hope this can be fixed. -- https://bugs.ruby-lang.org/

1 0