#3071

Extend generator filtering to support element ranges

Openhorenmaropened 8mo ago

Note that all the ideas here are fully backwards compatible, so the extension can be implemented without a breaking change

The recently-added generator filtering only allows filtering to a singular element. This can be extended to support multiple elements and/or element ranges.

For multiple separate elements, we can reuse the concept of commas as "OR" from the test specs. This would then mean that -g 1,3,4 filters the generator to indices 1, 3, and 4. For element ranges, we can use the start-end format, so that -g 1-4 would filter the generator to indices 1, 2, 3, and 4.

These two should also be combinable, so that -g 1,3,6-10 filters the generator to indices 1, 3, 6, 7, ..., 10.

Examples

Accepted

  • -g 1,2 - Elements at indices 1 and 2.
  • -g 1-3 - Elements at indices 1, 2, and 3.
  • -g 1-1 - Single element range, only the element at index 1.
  • -g 1-3,4,5-10 - Elements at indices 1,...,10.

Rejected

  • -g 1-3,2-4 - The two element ranges are overlapping
  • -g 3,2,1 - Elements are in bad order, must be monotonically increasing
  • -g 3-1 - Range is decreasing, see above
  • -g 1,2,2,3 - 3rd element is duplicated
  • -g -2 - Negative number, should still be rejected
  • -g 1--2 - Syntactically invalid
  • -g 1-2-3 - Syntactically invalid

Design questions

  • Should the ranges be closed? Programming usually uses half-open ranges, but closed-ranges feel more intuitive for specifying the range on the command line.

  • Should we error out on bad-but-fixable filters? Erroring out is less confusing, but fixing can be more user friendly.

    • Duplicated indices can be deduplicated.
    • Unsorted indices can be sorted
    • Overlapping ranges could be merged
  • Should we support partially-specified ranges?

    • 3-* could mean "From 4th element to the end of the generator"

Activity

1
oaksprout3mo ago

Would you want this one done? — Extend Catch2's -g/generator-index CLI filter to accept comma-separated lists and dash ranges (e.g. -g 1,3,6-10), not just a single index, per the accepted/rejected syntax table in the issue. If yes, we'll do it and open a PR; if not, say so (or just ignore this) and we won't touch it.

How it works: an AI agent does the work against your write-up; it's independently checked in a clean container (your test suite, network off) before anything reaches you; a human reviews it, submits it, and answers the review. You keep full control — nothing lands unless you merge it.

Recent examples of the same flow on other projects: https://github.com/pypa/pip-audit/pull/1089, https://github.com/sigstore/sigstore-python/pull/1845, https://github.com/openstreetmap/iD/pull/12631.

We're testing whether work offered this way is useful to maintainers — a blunt "no" is as helpful as a yes.