Project

General

Profile

Feature #13083

{String|Symbol}#match{?} with nil returns falsy as Regexp#match{?}

Added by kachick (Kenichi Kamiya) over 2 years ago. Updated over 2 years ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:78891]

Description

Just for consistency

Currently behaves as ( ruby --version: ruby 2.5.0dev (2016-12-28 trunk 57228) [x86_64-darwin16] )

'string'.__send__(:=~, nil) #=> nil
'string'.match(nil)         #=> TypeError: wrong argument type nil (expected Regexp)
'string'.match?(nil)        #=> TypeError: wrong argument type nil (expected Regexp)
:symbol.__send__(:=~, nil)  #=> nil
:symbol.match(nil)          #=> TypeError: wrong argument type nil (expected Regexp)
:symbol.match?(nil)         #=> TypeError: wrong argument type nil (expected Regexp)
/regex/.__send__(:=~, nil)  #=> nil
/regex/.match(nil)          #=> nil
/regex/.match?(nil)         #=> false

Expected to

'string'.__send__(:=~, nil) #=> nil
'string'.match(nil)         #=> nil
'string'.match?(nil)        #=> false
:symbol.__send__(:=~, nil)  #=> nil
:symbol.match(nil)          #=> nil
:symbol.match?(nil)         #=> false
/regex/.__send__(:=~, nil)  #=> nil
/regex/.match(nil)          #=> nil
/regex/.match?(nil)         #=> false

History

Updated by nobu (Nobuyoshi Nakada) over 2 years ago

  • Description updated (diff)

Updated by snood1205 (Eli Sadoff) over 2 years ago

I think that the way it currently exists is logical. As =~ is an Object method, it is worth while keeping the more permissible behavior whereas errors should be thrown for match and match? if nil is passed. The change that I would propose would actually to have Regexp#match and Regexp#match? both raise a type error if nil is passed as an argument. The inconsistency seems to be stronger there.

Updated by matz (Yukihiro Matsumoto) over 2 years ago

Those methods (but =~) should consistently raise exceptions.

Matz.

Also available in: Atom PDF