Workaround "flip-flop deprecated" warning in Ruby

Question

I invoke Ruby from my shell script like this:

ruby -n -e "print if %r($fromre)...%r($tore)" "$@"

Since Ruby 2.6, I get the warning

warning: flip-flop is deprecated

So it seems that i have to be prepared that the wise high priests of Ruby have decided that this (IMO useful) construct will be completely gone one day.

What would be an easy work-around? Of course I can replace

print if %r($fromre)...%r($tore)

by

inside ||= %r($fromre)
if inside
  print
  inside = false if %r($tore)
end

but I wonder whether there is a more concise way to write this.

Embodiment

The removal is still open / being discussed: bugs.ruby-lang.org/issues/5400. As a user of the flip flop operator, you might want to chime in. – Blackthorn

As far as I know, Rubinius doesn't even implement flip-flop, and so far, nobody seems to have noticed. Also, the Ruby Language Specification does not specify the flip-flop operator, so any code that uses it, is outside the spec anyhow. – Caiman

@JörgWMittag It'd be really nice to have a repeatable range operator which would act as a flip-flop at length 2. – Espousal

@JörgWMittag : Not quite correct. See the docs for 2.4 and scroll down to the chapter headed "Flip-Flop". You even find it in the 2.6 docs, interestingly without any mentioning that this is a deprecated feature. – Embodiment

@user1934428: Those links are to the documentation of YARV, not the Ruby Specification. In the Ruby Community, there are a couple of things that are considered "the Ruby Specification": the ISO Ruby Specification (doesn't mention flip-flop at all), the book The Ruby Programming Language written by David Flanagan and matz himself (doesn't mention flip-flop at all), the book Programming Ruby written by Dave Thomas and Andy Hunt (doesn't … – Caiman

… mention flip-flop at all), the RubySpec suite (mentions flip-flop but explicitly marks it deprecated), and "the code that is accepted by all Ruby implementations" (several implementations don't implement flip-flop). Chris Seaton (the lead developer of TruffleRuby) made an analysis of flip-flops, by downloading the entire archive of rubygems.org. The result: out … – Caiman

… of every single version of every single RubyGem in existence, flip-flop is used in a total of 8 gems a total of 10 times by a total of 5 developers. The full archive contains every version of every gem ever released on rubygems.org, a total of 1.6 billion lines of code, with 69 instances of flip-flop or around 1 in 23 million lines of code. The code to implement flip-flop in TruffleRuby is significantly longer than all code that uses flip-flop combined. – Caiman

Note also that Chris mentions that this language feature is different from some others such as $SAFE levels, continuations, ObjectSpace, etc. in that those ones have deep impact on the design of the VM and the kinds of optimizations that can be performed, whereas flip-flop is semantically trivial. So, there are fundamental reasons not to support one of those semantically invasive features but really no fundamental reasons not to support flip-flop (which is why TruffleRuby chose to implement it, despite the fact it's so rarely used). – Caiman

@JörgWMittag : I have seen the discussion bugs.ruby-lang.org, mentioned by Stefan. I can understand that the Ruby developers want to remove a language feature which is troublesome to understand. As a mere user, I just can express that I find it useful. But we don't discuss here, whether or not the deprecation is OK. I just wanted to object your position that it is not described in the language spec. – Embodiment

@Embodiment "the Ruby developers want to remove a language feature [...]" – note that the request to remove it came from a user. nobu (Ruby core dev) even said "I STRONGLY object removal of flip-flop, in "-e" option at least.". – Blackthorn

Answer 1

In July 2019 the original author of Ruby agreed to leave flip-flops in the language:

I hear the negative feedback from the community. OK, I give up. The warning should be removed.

Matz.

The warning was removed shortly thereafter and the change was backported to Ruby 2.6.

Hence