bug#29343: 27.0.50; Match data doesn't contain elements for non-matched subgroups

[Noam Postavsky <npostavs@gmail.com>]

Philipp Stephani <p.stephani2@gmail.com> writes:

> Am Sa., 17. März 2018 um 01:37 Uhr schrieb Noam Postavsky <npostavs@gmail.com>:
>>
>> Philipp Stephani <p.stephani2@gmail.com> writes:
>>
>> > $ emacs -Q -batch -eval '(progn (string-match "^\\(a\\)?\\(b\\)\\(c\\)?$" "b") (print (match-data)))'
>> > (0 1 nil nil 0 1)
>> >
>> > Note that neither the `a` nor the `c` group matched, but there are
>> > entries for `a` in `match-data`, but not for `c`.  This makes working
>> > with the match data unnecessarily hard because its length depends on
>> > whether certain optional groups have matched or not.  I haven't seen any
>> > discussion about this behavior in either the manual or the docstring.  I
>> > think the match data in this case should be (0 1 nil nil 0 1 nil nil).
>>
>> You can get that result by passing a list of the expected length as the
>> REUSE argument to match-data:
>
> True, but that also requires knowing the expected length. In the most
> general case this should work for unknown regular expressions.

I don't understand how the general case you describe could occur.  If
you don't know the expected length, that means you don't what groups are
in the regexp, so you can only rely on group 0 existing, i.e., you only
care about the first two elements in the match-data.