Ruby 2.4.0 introduced #match? for this, lets do the same.
You could use var2 === var1 instead but you have to switch the arguments around... #match? is more readable than both ?~ and ===.
Edit: Note #match? is also defined on Regex, so works both ways unlike ===:

$ irb
2.4.1 :001 > "hello".match?(/he/)
 => true
2.4.1 :002 > /he/.match?("hello")
 => true
2.4.1 :003 > /he/ === "hello"
 => true
2.4.1 :004 > "hello" === /he/
 => false

There's no need to do !! because the result is MatchData or Nil, so truthy or falsey.

@asterite unfortunately, there is a need for it, since at times you'd like to have a Bool return type value instead of Regex::MatchData | Nil.

I'll stick to fixing bugs. Maybe someone else can decide this better :-)

In any case, the introduction of new operators must be very strongly justified.

So this pull request should be rejected. But You can add usual method.

P.S.: I'm glad to see how simple it is to expand the language

@asterite I think having a strong opinion guiding the project is better than design by committee. I argued against some of your decisions in the past but it turns out that you were almost always right in the long run!

Having too many operators is a bad thing, I think we have enough already. Using !!(var1 =~ var2) is short enough, and requires no new operators just for when you want to return var1 =~ var2 from a function or expression.

@RX14 I agree. It's just that I don't want to take decisions alone anymore. All decisions should be discussed by the whole core team. Here I rushed to close this because I'm against it, but I didn't consult it with anyone else.

@asterite I was referring to the need of having Bool return value but this can be easily achieved by adding Regex/String#match? method like Ruby 2.4 did. Having said that, I'm against this PR as well as adding new operators as a means to achieve before mentioned goal.

I agree with limiting the number of operators in premise, but in this instance I'd agree with @reitermarkus that it does seem rather counterintuitive to provide the negative !~ but not have a positive equivalent, so on that basis I'd be for it.

Ruby 2.4.0 introduced #match? for this, lets do the same.

Ruby didn't actually introduce it for this, the reason was to remove the unnessary assignment to $~ when only the return value is of interest.

Having too many operators is a bad thing, I think we have enough already.

Why is it a bad thing? It's not so much about the operators themselves, it's more about their usage, which in this case, is very specific.

Using !!(var1 =~ var2) is short enough, and requires no new operators just for when you want to return var1 =~ var2 from a function or expression.

!(var1 =~ var2) is even shorter than !!(var1 =~ var2), so should we remove the !~ operator just for that reason?

I think ?~ is the logical counterpart for !~, and fits better than match? and !~.

As outlined by @asterite, there is no need for such an operator. It already works:

if "something" =~ /regexp/
  # match
end

Maybe a match? method that wouldn't assign a matchdata but only return a boolean would allow some optimisation. Yet, introducing another operator seems overkill.

Closing since there is enough consensus that we prefer not to create new operators without compelling reasons. In this case the general opinion is we can live without this.