title: Why is there no way to return typed groups in a regular expression matcher?
body: <p>I've just finished reviewing some code, which was a regular expression that 'parsed', in the loosest sense of the word, a fair few numbers from a string.</p>
  
  <p>Simple example being: </p>
  
  <pre><code>^([0-9]{1}) ([0-9]{2}) ([0-9]{1}) .... and so on$ 
  </code></pre>
  
  <p>Which should match '3 4 5 ..... and so on', if I'm not mistaken.</p>
  
  <p>It seemed like, due to the amount of numbers that were being checked in the string and how complex the string was in the case I'm referring to, that indeed a regular expression was potentially the right way to go about matching but when trying to extract the numbers, the author of the code was having to do a fair few calls to the following method with the matcher group: -</p>
  
  <pre><code>Integer.parseInt(matcher.group(index))
  </code></pre>
  
  <p>If a regular expression engine is explicitly being told to capture a group that contains only 0-9 {1-2}, is there no way to explicitly capture the correct type so as not to parse again? In this case, should the pattern be matched without using a regular expression, depending upon how complex the pattern is? Perhaps my understanding of how a regular expression group matcher works is not complete.</p>
  
  <p>Do other languages support this?</p>
  
  <p><em>I suppose implementing a light weight parseInt without the error checking branches would be a slight performance improvement if I were so inclined to 'squeeze' out that last bit of performance. Looking at the parseInt method, there's a fair few branches for error checking that might not be needed after a regex match</em></p>