[#114936] [Ruby master Feature#19908] Update to Unicode 15.1 — "nobu (Nobuyoshi Nakada) via ruby-core" <ruby-core@...>

Issue #19908 has been reported by nobu (Nobuyoshi Nakada).

24 messages 2023/10/02

[#115016] [Ruby master Bug#19921] TestYJIT#test_bug_19316 test failure — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19921 has been reported by vo.x (Vit Ondruch).

21 messages 2023/10/12

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

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

12 messages 2023/10/13

[#115068] [Ruby master Bug#19929] Warnings for `mutex_m`, `drb` and `base64` appears while the gem spec has explicit dependencies — "yahonda (Yasuo Honda) via ruby-core" <ruby-core@...>

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

8 messages 2023/10/17

[#115071] [Ruby master Misc#19931] to_int is not for implicit conversion? — "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@...>

Issue #19931 has been reported by Dan0042 (Daniel DeLorme).

16 messages 2023/10/17

[#115139] [Ruby master Bug#19969] Regression of memory usage with Ruby 3.1 — "hsbt (Hiroshi SHIBATA) via ruby-core" <ruby-core@...>

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

8 messages 2023/10/24

[#115165] [Ruby master Bug#19972] Install default/bundled gems into dedicated directories — "vo.x (Vit Ondruch) via ruby-core" <ruby-core@...>

Issue #19972 has been reported by vo.x (Vit Ondruch).

11 messages 2023/10/25

[#115196] [Ruby master Feature#19979] Allow methods to declare that they don't accept a block via `&nil` — "ufuk (Ufuk Kayserilioglu) via ruby-core" <ruby-core@...>

Issue #19979 has been reported by ufuk (Ufuk Kayserilioglu).

21 messages 2023/10/29

[ruby-core:115084] [Ruby master Bug#19932] Regexp o modifier freeze interpolation between method calls

From: "noraj-acceis (Alexandre ZANNI) via ruby-core" <ruby-core@...>
Date: 2023-10-18 14:29:56 UTC
List: ruby-core #115084
Issue #19932 has been updated by noraj-acceis (Alexandre ZANNI).


I'm not sure I was clear.

It's not that clear reading the documentation that the "freeze" will continue to live outside the local scope. All examples are always outside a method definition. As for local variables I would expect `myregexp = /#{myvar}/o` to be re-evaluated between several method calls. By reading the doc I understood the regexp object will be frozen in a local context (e.g. in a loop) but if it's I put that in a method I understood the regexp object will be frozen locally during the method call but that it will be dynamically re-evaluated in another method call then re-frozen for that new call duration.

If that's still the expected behavior, it could be nice then to introduce another modifier that will unfroze the regexp object when leaving the method call so that a use case like in the PoC would work. Because there are many use case where you want a regexp object to be frozen for example because you have a loop with 1M items where the regexp will be called o neach item but you still want to be able to call the method again with different arguments.

----------------------------------------
Bug #19932: Regexp o modifier freeze interpolation between method calls
https://bugs.ruby-lang.org/issues/19932#change-104956

* Author: noraj-acceis (Alexandre ZANNI)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Taken the following PoC:

```ruby
def poc(regexp)
  hs = [
    'azerty',
    'azertyui',
    'azertyuiop'
  ]
  out = []
  hs.each do |h|
    out << h if /#{regexp}/.match?('azerty')
  end
  out
end

p poc('az')
p poc('wxc')
```

I have the following output:

```ruby
["azerty", "azertyui", "azertyuiop"]
[]
```

Now because the regexp never change inside the method once set I could add the `o` modifier so that `#{}` interpolation is computed only once.

So the PoC becomes:

```ruby
def poc(regexp)
  hs = [
    'azerty',
    'azertyui',
    'azertyuiop'
  ]
  out = []
  hs.each do |h|
    out << h if /#{regexp}/o.match?('azerty')
  end
  out
end

p poc('az')
p poc('wxc')
```

Output:

```
["azerty", "azertyui", "azertyuiop"]
["azerty", "azertyui", "azertyuiop"]
```

So each future call to the method will be equals to the result of the first call because the regexp is "frozen".

I was expecting the regexp to be "frozen" only for the current call in an effort of performance but instead it's "frozen" for future calls too.

Another example of usage of `o` modifier here: https://learnbyexample.github.io/Ruby_Regexp/modifiers.html#o-modifier

So is that a side effect or is that the expected behavior?



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

In This Thread