[#107867] Fwd: [ruby-cvs:91197] 8f59482f5d (master): add some tests for Unicode Version 14.0.0 — Martin J. Dürst <duerst@...>
To everybody taking care of continuous integration:
3 messages
2022/03/13
[#108090] [Ruby master Bug#18666] No rule to make target 'yaml/yaml.h', needed by 'api.o' — duerst <noreply@...>
Issue #18666 has been reported by duerst (Martin D端rst).
7 messages
2022/03/28
[#108117] [Ruby master Feature#18668] Merge `io-nonblock` gems into core — "Eregon (Benoit Daloze)" <noreply@...>
Issue #18668 has been reported by Eregon (Benoit Daloze).
22 messages
2022/03/30
[ruby-core:107807] [Ruby master Bug#18580] Range#include? inconsistency for beginless String ranges
From:
"jeremyevans0 (Jeremy Evans)" <noreply@...>
Date:
2022-03-09 22:22:01 UTC
List:
ruby-core #107807
Issue #18580 has been updated by jeremyevans0 (Jeremy Evans).
This was discussed during the February 2022 developer meeting, and @matz said he needs more time to consider it.
----------------------------------------
Bug #18580: Range#include? inconsistency for beginless String ranges
https://bugs.ruby-lang.org/issues/18580#change-96735
* Author: zverok (Victor Shepelev)
* Status: Open
* Priority: Normal
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN
----------------------------------------
The follow-up of #18577.
`Range#include?` is [specialized for strings](https://github.com/ruby/ruby/blob/master/range.c#L1782). For all I can tell, this behavior is relatively new: it emerged when switching `#===` to use `#cover?` instead of `#include?`:
* in 2.6, it was decided that String Ranges should continue to use `#include?` (#14575)
* ...but in 2.7, it was decided that they should use `#cover?` as all others (#15449)
The "despecialization" in 2.7 was actually done by adding more specialization in `range_include_internal`.
This leads to the following:
```ruby
# default Range behavior:
(..Date.today).include? Date.today
# (irb):10:in `each': can't iterate from NilClass (TypeError)
# String Range behavior:
(..'z').include?('w')
# => true
```
Why I think **it is bad**:
1. This is a leftover of the relatively recent change; why it is 3 versions old, I doubt there is a lot of code relying on this quirk (only beginless ranges are affected)
2. The more "invisible specialization", the more possibility of bugs (as #18577 shows)
3. It is easy to stumble upon while learning Ruby/experimenting (strings and ranges are the most basic objects to be seen in many examples and courses), and to become confused, because there is no reasonable explanation for the semantics other than "well... for String, it is so"
4. It *can* be said that the String ranges behavior have the same specialization as Numeric ones, but it is not so; while Numeric Ranges specialization is long-living legacy, it is at least consistent (`#include?` just behaves like `#cover?` for them, always):
Numerics:
```ruby
(1...3).include? 1.5
# => true, like #cover?
(...3).include? 1.5
# => true, same, the explanation is "just like #cover?"
```
Strings:
```ruby
('a'..'z').include?('ww')
# => false, like #include? for any other type
(..'z').include?('ww')
# => true, this is deeply confusing
```
--
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>