[#108176] [Ruby master Bug#18679] Encoding::UndefinedConversionError: "\xE2" from ASCII-8BIT to UTF-8 — "taf2 (Todd Fisher)" <noreply@...>

Issue #18679 has been reported by taf2 (Todd Fisher).

8 messages 2022/04/05

[#108185] [Ruby master Feature#18683] Allow to create hashes with a specific capacity. — "byroot (Jean Boussier)" <noreply@...>

Issue #18683 has been reported by byroot (Jean Boussier).

13 messages 2022/04/06

[#108198] [Ruby master Feature#18685] Enumerator.product: Cartesian product of enumerators — "knu (Akinori MUSHA)" <noreply@...>

Issue #18685 has been reported by knu (Akinori MUSHA).

8 messages 2022/04/08

[#108201] [Ruby master Misc#18687] [ANN] Upgraded bugs.ruby-lang.org to Redmine 5.0 — "hsbt (Hiroshi SHIBATA)" <noreply@...>

Issue #18687 has been reported by hsbt (Hiroshi SHIBATA).

10 messages 2022/04/09

[#108216] [Ruby master Misc#18691] An option to run `make rbconfig.rb` in a different directory — "jaruga (Jun Aruga)" <noreply@...>

Issue #18691 has been reported by jaruga (Jun Aruga).

14 messages 2022/04/12

[#108225] [Ruby master Misc#18726] CI Error on c99 and c2x — "znz (Kazuhiro NISHIYAMA)" <noreply@...>

Issue #18726 has been reported by znz (Kazuhiro NISHIYAMA).

11 messages 2022/04/14

[#108235] [Ruby master Bug#18729] Method#owner and UnboundMethod#owner are incorrect after using Module#public/protected/private — "Eregon (Benoit Daloze)" <noreply@...>

Issue #18729 has been reported by Eregon (Benoit Daloze).

28 messages 2022/04/14

[#108237] [Ruby master Bug#18730] Double `return` event handling with different tracepoints — "hurricup (Alexandr Evstigneev)" <noreply@...>

Issue #18730 has been reported by hurricup (Alexandr Evstigneev).

8 messages 2022/04/14

[#108294] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces — sos4nt <noreply@...>

Issue #18743 has been reported by sos4nt (Stefan Schテシテ殕er).

20 messages 2022/04/19

[#108301] [Ruby master Bug#18744] I used Jazzy to generate the doc for my iOS library, but it showed me a bug — "zhaoxinqiang (marc steven)" <noreply@...>

Issue #18744 has been reported by zhaoxinqiang (marc steven).

8 messages 2022/04/20

[ruby-core:108326] [Ruby master Bug#18155] (nil..nil).cover?(x) is true for all x since beginless ranges were introduced

From: "matz (Yukihiro Matsumoto)" <noreply@...>
Date: 2022-04-21 06:36:00 UTC
List: ruby-core #108326
Issue #18155 has been updated by matz (Yukihiro Matsumoto).

Status changed from Open to Closed

We consider `nil .. nil` as a begin-less end-less range, so that we keep the current (post 2.7) behavior.
Probably we should add description in the document.

Matz.


----------------------------------------
Bug #18155: (nil..nil).cover?(x) is true for all x since beginless ranges were introduced
https://bugs.ruby-lang.org/issues/18155#change-97347

* Author: urbanautomaton (Simon Coffey)
* Status: Closed
* Priority: Normal
* ruby -v: 2.7.0 and greater
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
### Description

The introduction of beginless ranges in #14799 changed the behaviour of `Range#cover?` when both the beginning and the end of a `Range` are `nil`. Previously such a range would cover no values; now it covers all values:

```
irb-2.6.6> (nil..nil).cover?("23 dogs")
=> false

irb-2.7.0> (nil..nil).cover?("23 dogs")
=> true
```

This change was [noted at the time](https://bugs.ruby-lang.org/issues/14799#note-12), but it was believed that the call would have previously raised an error instead of returning `false`. I've not exhaustively checked, but the old behaviour goes back to at least ruby 2.2.

### Discussion

I'm not sure that either of these results are "correct", since I'm not sure that the concept of a range with no beginning or end is meaningful. Without either parameter, it seems impossible to infer the values it ranges over, since we have no type information available.

However, I did find both the current result and the change in behaviour quite surprising, so I've opened this issue.

Some options I considered:

1. **Do nothing:** a beginless-and-endless range is unbounded in both value and type, so covers all values of all types
2. **Reinstate the old behaviour:** a beginless-and-endless range has no type, so covers no values
3. **Raise an error:** a beginless-and-endless range is meaningless, so constructing one should raise an error

My personal preference is option 3, but I can clearly see that it represents the most effort. I'd welcome people's thoughts; if option 1 is preferred, I'd be happy to contribute a documentation patch to make the new behaviour clear.

---Files--------------------------------
range-18155.patch (1.08 KB)


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

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next