perlre says:

If multiple distinct capture buffers have the same name then the $+{NAME} will refer to the leftmost defined buffer in the match.

However, what puzzles me and should be apparent is that nothing at all was captured.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

Since the "leftmost defined buffer" is inside of a group quantified by {0}, it isn't puzzling to me that this buffer didn't match. And it isn't surprising that a buffer that didn't match doesn't capture anything.

Perhaps you were now expecting thing => undef, contrary to your previously stated expectation? If so, my limited testing shows that %+ keys aren't pre-populated but the values are returned by magic (%+ always appears empty even when $+{moo} returns "o" after 'cow' =~ /(?<moo>o+)/).

Update: I'm glad to report that the lack of keys in %+ appears to have only been an effect of the quick-hack method I used to test, related to evaluation order problems.

- tye        

 ( ... ){0}
[download]

First, {0} should be outright illegal, because it tends to be used (without effect) by newbies who say "I want this section to contain no K's, so I'll put K{0}".

Second, even if it is legal, as it appears to be, I'd expect any decent optimizer to just completely eliminate it.

So I'm surprised you expected any sort of utility out of your regex.

I guess I was just surprised to find this something that's more possible in Ruby-1.9. I'll still probably end up just translating to a proper parser but it was easy to use the regexp engine to start with. The below snippet is equivalent to my perl but does return the capture.

require 'pp'
re = %r{
  # Grammar rules go here
  (?:
    (?<thing>.+)
  ){0}

  # Invoke grammar here
  \g<thing>
}
m = re.match( 'text' )
puts m['thing'] # puts "text\n"
[download]

(?<thing>.+) never matched "text" (backtracking occurred), so it's clearly a major bug in ruby if your code showed it did.