[#99426] [Ruby master Bug#17098] Float#negative? reports negative zero as not negative — chris@...

Issue #17098 has been reported by chrisseaton (Chris Seaton).

12 messages 2020/08/01

[#99449] [Ruby master Bug#17100] Ractor: a proposal for new concurrent abstraction without thread-safety issues — ko1@...

Issue #17100 has been reported by ko1 (Koichi Sasada).

41 messages 2020/08/03

[#99474] [Ruby master Feature#17103] Add a :since option to ObjectSpace.dump_all — jean.boussier@...

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

9 messages 2020/08/04

[#99485] [Ruby master Misc#17104] Why are interpolated string literals frozen? — bughitgithub@...

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

23 messages 2020/08/05

[#99499] [Ruby master Bug#17105] A single `return` can return to two different places in a proc inside a lambda inside a method — eregontp@...

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

10 messages 2020/08/06

[#99582] [Ruby master Feature#17122] Add category to Warning#warn — eileencodes@...

Issue #17122 has been reported by eileencodes (Eileen Uchitelle).

20 messages 2020/08/13

[#99700] [Ruby master Bug#17129] bundle install `eventmachine` and `sassc` fails since 914b2208ab3eddec478cdc3e079e6c30d0f0892c — yasuo.honda@...

SXNzdWUgIzE3MTI5IGhhcyBiZWVuIHJlcG9ydGVkIGJ5IHlhaG9uZGEgKFlhc3VvIEhvbmRhKS4N

9 messages 2020/08/26

[ruby-core:99702] [Ruby master Bug#17030] Enumerable#grep{_v} should be optimized for Regexp

From: fatkodima123@...
Date: 2020-08-26 08:31:48 UTC
List: ruby-core #99702
Issue #17030 has been updated by fatkodima (Dima Fatko).


sawa (Tsuyoshi Sawada) wrote in #note-10:
> I feel scivola20 (sciv ola)'s idea promising, but have a concern that it is going to introduce the same kind of mess as when `"string"f` notation was introduced (same "f" used due to frozen and fast, but this is just coincidental). People are going to need to write `/regex/f` all over the place.
> 
> Just by analogy from the situation with strings, what about introducing the following pragma, which will make all regex literals on that page fast regex literals (i.e., `===` becomes `match?`)?
> 
> ```ruby
> # boolean_regex_literal: true
> ```
> 
> And perhaps in the long run, Matz might want to make all regexes work like that, or simply change the definition of `Regexp#===`.


Yes, seems like this will solve the problem of typing `regex/f` all over. Does it also mean that we then should have something like in frozen string world (`String#@+`) to manually change to the old behavior where we need it, like

```ruby
# boolean_regex_literal: true

case var
when /foo/
  # does not set $~, etc
when +/bar/
  # sets $~, etc
end
```
?

----------------------------------------
Bug #17030: Enumerable#grep{_v} should be optimized for Regexp
https://bugs.ruby-lang.org/issues/17030#change-87192

* Author: marcandre (Marc-Andre Lafortune)
* Status: Open
* Priority: Normal
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
Currently:

```ruby
array.select { |e| e.match?(REGEXP) }

# about 3x faster and 6x more memory efficient than
array.grep(REGEXP)
```

This is because `grep` calls `Regexp#===` which creates useless `MatchData`



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

Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread