[#113407] [Ruby master Feature#19630] [RFC] Deprecate `Kernel.open("|command-here")` due to frequent security issues — "postmodern (Hal Brodigan) via ruby-core" <ruby-core@...>

Issue #19630 has been reported by postmodern (Hal Brodigan).

19 messages 2023/05/05

[#113430] [Ruby master Feature#19633] Allow passing block to `Kernel#autoload` as alternative to second `filename` argument — "shioyama (Chris Salzberg) via ruby-core" <ruby-core@...>

Issue #19633 has been reported by shioyama (Chris Salzberg).

16 messages 2023/05/09

[#113489] [Ruby master Bug#19642] Remove vectored read/write from `io.c`. — "ioquatix (Samuel Williams) via ruby-core" <ruby-core@...>

Issue #19642 has been reported by ioquatix (Samuel Williams).

10 messages 2023/05/15

[#113498] [Ruby master Feature#19644] Module::current to complement Module::nesting — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19644 has been reported by bughit (bug hit).

12 messages 2023/05/16

[#113517] [Ruby master Misc#19679] Migrate Wiki from bugs.ruby-lang.org to ruby/ruby GitHub repository — "jemmai (Jemma Issroff) via ruby-core" <ruby-core@...>

Issue #19679 has been reported by jemmai (Jemma Issroff).

11 messages 2023/05/18

[#113529] [Ruby master Bug#19681] The final classpath of partially named modules is sometimes inconsistent once permanently named — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>

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

34 messages 2023/05/19

[#113538] [Ruby master Feature#19682] ability to get a reference to the "default definee" — "bughit (bug hit) via ruby-core" <ruby-core@...>

Issue #19682 has been reported by bughit (bug hit).

28 messages 2023/05/19

[#113601] [Ruby master Bug#19687] Should a development version of the standard library be included in ruby/ruby? — "jaruga (Jun Aruga) via ruby-core" <ruby-core@...>

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

9 messages 2023/05/23

[#113632] [Ruby master Bug#19691] Case insensitive file systems, require filename casing — "MSP-Greg (Greg L) via ruby-core" <ruby-core@...>

Issue #19691 has been reported by MSP-Greg (Greg L).

7 messages 2023/05/24

[#113656] [Ruby master Misc#19693] Data initialization is significantly slower than Struct — janosch-x via ruby-core <ruby-core@...>

Issue #19693 has been reported by janosch-x (Janosch M=FCller).

13 messages 2023/05/25

[#113660] [Ruby master Feature#19694] Add Regexp#timeout= setter — "aharpole (Aaron Harpole) via ruby-core" <ruby-core@...>

Issue #19694 has been reported by aharpole (Aaron Harpole).

15 messages 2023/05/25

[#113676] [Ruby master Bug#19697] Resolv::DNS resolution for international domains fails with "Encoding::CompatibilityError: incompatible character encodings: UTF-8 and ASCII-8BIT" — "clairity (claire c) via ruby-core" <ruby-core@...>

SXNzdWUgIzE5Njk3IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IGNsYWlyaXR5IChjbGFpcmUgYykuDQ0K

6 messages 2023/05/27

[ruby-core:113436] [Ruby master Feature#18368] Range#step semantics for non-Numeric ranges

From: janosch-x via ruby-core <ruby-core@...>
Date: 2023-05-09 19:07:32 UTC
List: ruby-core #113436
Issue #18368 has been updated by janosch-x (Janosch M=FCller).





This is a cool improvement! I think it's fine to keep the special String be=
havior, and maybe that of Symbols. These special cases are not counterintui=
tive as there is no naturally intuitive way for them to behave. The burden =
on the language also looks manageable as it seems unlikely that a lot of co=
mplexity will be built on top of this part in particular.=20



----------------------------------------

Feature #18368: Range#step semantics for non-Numeric ranges

https://bugs.ruby-lang.org/issues/18368#change-103008



* Author: zverok (Victor Shepelev)

* Status: Open

* Priority: Normal

----------------------------------------

I am sorry if the question had already been discussed, can't find the relev=
ant topic.



"Intuitively", this looks (for me) like a meaningful statement:



```ruby

(Time.parse('2021-12-01')..Time.parse('2021-12-24')).step(1.day).to_a

#                                                         ^^^^^ or just 24*=
60*60

```

Unfortunately, it doesn't work with "TypeError (can't iterate from Time)".

Initially it looked like a bug for me, but after digging a bit into code/do=
cs, I understood that `Range#step` has an odd semantics of "advance the beg=
in N times with `#succ`, and yield the result", with N being always integer:

```ruby

('a'..'z').step(3).first(5)

# =3D> ["a", "d", "g", "j", "m"]

```



The fact that semantic is "odd" is confirmed by the fact that for Float it =
is redefined to do what I "intuitively" expected:

```ruby

(1.0..7.0).step(0.3).first(5)

# =3D> [1.0, 1.3, 1.6, 1.9, 2.2]=20

```

(Like with [`Range#=3D=3D=3D` some time ago](https://bugs.ruby-lang.org/iss=
ues/14575), I believe that to be a strong proof of the wrong generic semant=
ics, if for numbers the semantics needed to be redefined completely.)



Another thing to note is that "skip N elements" seem to be rather "generica=
lly Enumerable-related" yet it isn't defined on `Enumerable` (because nobod=
y needs this semantics, typically!)



Hence, two questions:

* Can we redefine generic `Range#step` to new semantics (of using `begin + =
step` iteratively)? It is hard to imagine the amount of actual usage of the=
 old behavior (with String?.. to what end?) in the wild

* If the answer is "no", can we define a new method with new semantics, lik=
e, IDK, `Range#over(span)`?



**UPD:** More examples of useful behavior (it is NOT only about core `Time`=
 class):



```ruby

require 'active_support/all'



(1.minute..20.minutes).step(2.minutes).to_a

#=3D> [1 minute, 3 minutes, 5 minutes, 7 minutes, 9 minutes, 11 minutes, 13=
 minutes, 15 minutes, 17 minutes, 19 minutes]



require 'tod'



(Tod::TimeOfDay.parse("8am")..Tod::TimeOfDay.parse("10am")).step(30.minutes=
).to_a=20

#=3D> [#<Tod::TimeOfDay 08:00:00>, #<Tod::TimeOfDay 08:30:00>, #<Tod::TimeO=
fDay 09:00:00>, #<Tod::TimeOfDay 09:30:00>, #<Tod::TimeOfDay 10:00:00>]





require 'matrix'

(Vector[1, 2, 3]..).step(Vector[1, 1, 1]).take(3)

#=3D> [Vector[1, 2, 3], Vector[2, 3, 4], Vector[3, 4, 5]]



require 'unitwise'

(Unitwise(0, 'km')..Unitwise(1, 'km')).step(Unitwise(100, 'm')).map(&:to_s)

#=3D> ["0 km", "1/10 km", "1/5 km", "3/10 km", "2/5 km", "0.5 km", "3/5 km"=
, "7/10 km", "4/5 km", "9/10 km", "1 km"]

```





**UPD:** Responding to discussion points:



**Q:** Matz is concerned that the proposed simple definition will be confus=
ing with the classes where `+` is redefined as concatenation.



**A:** I believe that simplicity of semantics and ease of explaining ("it j=
ust uses `+` underneath, whatever `+` does, will be performed") will make t=
he confusion minimal.



**Q:** Why not introduce new API requirement (like "class of range's `begin=
` should implement `increment` method, and then it will be used in `step`)



**A:** require *every* gem author to change *every* of their objects' behav=
ior. For that, they should be aware of the change, consider it important en=
ough to care, clearly understand the necessary semantics of implementation,=
 have a resource to release a new version... Then all users of all such gem=
s would be required to upgrade. The feature would be DOA (dead-on-arrival).



The two alternative ways I am suggesting: change the behavior of `#step` or=
 introduce a new method with desired behavior:

1. Easy to explain and announce

2. Require no other code changes to immediately become useful

3. With something like [backports](https://github.com/marcandre/backports) =
or [ruby-next](https://github.com/ruby-next/ruby-next) easy to start using =
even in older Ruby version, making the code more expressive even before it =
would be possible for some particular app/compny to upgrade to (say) 3.2



All examples of behavior from the code above are real `irb` output with mon=
key-patched `Range#step`, demonstrating how little change will be needed to=
 code outside of the `Range`.







--=20

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

 ______________________________________________
 ruby-core mailing list -- [email protected]
 To unsubscribe send an email to [email protected]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-c=
ore.ml.ruby-lang.org/

In This Thread