[#118180] [Ruby master Bug#20525] Percent string literal with indentation support — "bradgessler (Brad Gessler) via ruby-core" <ruby-core@...>

Issue #20525 has been reported by bradgessler (Brad Gessler).

8 messages 2024/06/04

[#118243] [Ruby master Feature#20564] Switch default parser to Prism — "kddnewton (Kevin Newton) via ruby-core" <ruby-core@...>

Issue #20564 has been reported by kddnewton (Kevin Newton).

11 messages 2024/06/07

[#118269] [Ruby master Bug#20570] Nokey behavior changed since 3.3. — "ksss (Yuki Kurihara) via ruby-core" <ruby-core@...>

Issue #20570 has been reported by ksss (Yuki Kurihara).

8 messages 2024/06/10

[#118279] [Ruby master Bug#20573] Warning.warn shouldn't be called for disabled warnings — "tenderlovemaking (Aaron Patterson) via ruby-core" <ruby-core@...>

Issue #20573 has been reported by tenderlovemaking (Aaron Patterson).

10 messages 2024/06/10

[#118281] [Ruby master Misc#20574] DevMeeting-2024-07-11 — "mame (Yusuke Endoh) via ruby-core" <ruby-core@...>

Issue #20574 has been reported by mame (Yusuke Endoh).

12 messages 2024/06/11

[#118346] [Ruby master Bug#20586] Some filesystem calls in dir.c are missing error handling and can return incorrect results if interrupted — "ivoanjo (Ivo Anjo) via ruby-core" <ruby-core@...>

Issue #20586 has been reported by ivoanjo (Ivo Anjo).

13 messages 2024/06/19

[#118347] [Ruby master Bug#20587] dir.c calls blocking system calls while holding the GVL — "ivoanjo (Ivo Anjo) via ruby-core" <ruby-core@...>

Issue #20587 has been reported by ivoanjo (Ivo Anjo).

7 messages 2024/06/19

[#118360] [Ruby master Bug#20588] RangeError: integer 132186463059104 too big to convert to 'int' since cdf33ed5f37f9649c482c3ba1d245f0d80ac01ce with YJIT enabled — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

Issue #20588 has been reported by yahonda (Yasuo Honda).

10 messages 2024/06/20

[#118388] [Ruby master Feature#20594] A new String method to append bytes while preserving encoding — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

SXNzdWUgIzIwNTk0IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGJ5cm9vdCAoSmVhbiBCb3Vzc2llciku

32 messages 2024/06/25

[ruby-core:118278] [Ruby master Bug#20180] Inconsistent evaluation of `**{}` depending on position in array

From: "k0kubun (Takashi Kokubun) via ruby-core" <ruby-core@...>
Date: 2024-06-10 23:06:34 UTC
List: ruby-core #118278
Issue #20180 has been updated by k0kubun (Takashi Kokubun).

Backport changed from 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED to 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: DONE

ruby_3_3 commit:40251ed0dfe99bb09c2fa542fce603ade25e3729.

----------------------------------------
Bug #20180: Inconsistent evaluation of `**{}` depending on position in array
https://bugs.ruby-lang.org/issues/20180#change-108772

* Author: ozydingo (Andrew Schwartz)
* Status: Closed
* ruby -v: 3.3
* Backport: 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED, 3.3: DONE
----------------------------------------
Reproduced on ruby:3.3 docker container

The evaluation of `**{}` differs if it appears alone (evaluates as empty / no content) in an array vs after another element (evaluates as an empty Hash).

```rb
args = []; kwargs = {}
[*args]
# => []
[**kwargs]
# => []
[*args, **kwargs]
# => [{}]
[*args] + [**kwargs] == [*args, **kwargs]
=> false
```

I claim this violates the Principle of Least Surprise. I will admit that beyond a thin example I will give below, I am struggling to come up with a more convincing pragmatic reason that this should be addressed, but due to how surprising it is and the bugs it cause our team I wanted to submit it for tracking. This may be related to https://bugs.ruby-lang.org/issues/20064?tab=notes though the issues are distinct.

Specifically, in my use case, I am writing a class responsible for adapting arguments in one form to another (json object to method args and vice versa). My tests broken when adding support for keyword args due to expectations of no args:

```
# RSpec
expect(foo).to have_received(:bar).with([]) # This now need `with([], {})`
```

Again, this is a bit thin as by itself this isn't problematic as I can add the `{}`. However, this does require that my test knows more about the implementation that it should. That is, my implementation might be

```
if kwargs.present?
  call(*args, **kwargs)
else
  call(*args)
end
```

This change does not change the behavior of the class, but will break the test. I therefore think this behavior of `**kwargs` is problematic.






-- 
https://bugs.ruby-lang.org/

In This Thread