Extracting non-existant submatches should be consistent

[Google Code Exporter]

Extracting a named submatch that doesn't exist gives an error, but
extracting a numbered submatch that doesn't exist gives #f. Either the
former should return #f or the latter should raise a similar error.

#;1> (load "irregex.scm")
; loading irregex.scm ...
#;2> (define r (irregex '(seq "foo")))
#;3> (define m (irregex-match r "foo"))
#;4> (irregex-match-substring m 'x)

Error: unknown match name: x
....
#;5> (irregex-match-substring m 5)
#f

Original issue reported on code.google.com by [e-mail] on 7 Apr 2010 at 6:57

[Google Code Exporter]

Good point, I just need to decide which I want them to do...

Original comment by [e-mail] on 5 Jul 2010 at 12:51

• Changed state: Accepted

[Google Code Exporter]

I think it ought to throw an error in both cases.  This makes it easier to 
detect bugs in code. Returning #f would then be purely for submatches that 
didn't match.

Original comment by [e-mail] on 1 Aug 2010 at 3:07

[Google Code Exporter]

This stuff is now concentrated in the procedure irregex-match-numeric-index

It has an argument strict? that when it's #t will cause it to raise an error 
when the index does not exist or return #f if strict? is #f. It currently only 
raises errors in case of named submatches, but it could easily be made to do 
the same for numeric indices.

The reason we have nonstrict numeric submtaches at all seems to be mostly for 
POSIX and PCRE compatibility; those can contain backrefs to undefined numeric 
submatches, which will generally not cause an error. If we want irregexes to be 
strict always we could make either those be more strict (at the risk of 
breaking compatibility with more lax implementations) or make a new "strict" 
option in the irregex and/or match objects.

Original comment by [e-mail] on 6 Aug 2010 at 7:47

[Google Code Exporter]

This has been done properly now, I think

Original comment by [e-mail] on 23 Oct 2010 at 3:10

• Changed state: Closed

[Google Code Exporter]

Fuck you Google

Original comment by [e-mail] on 23 Oct 2010 at 3:20

• Changed state: Fixed