fix: handle operators in constructor default arguments - #449

Reviewed the current diff and the regression paths. The bounds check prevents the IndexError from #223, and the operator handling preserves the existing template/function-parameter comma collapsing. I also ran pytest --no-cov locally on Python 3.12 / Windows: 231 passed.

Confirmed the fix at 2e8aa7d: A(int b, int c, int a = 1 << 1), A(int a = 1 << 1) and A(bool a = 1 < 2, int b = 0) all raise IndexError on develop and are clean here, with no change I could find on >>, >=, <=> or nested-template arguments. Full suite passes (206).

On @aranliu0130 's O(n) point, splitting on top-level commas in one pass drops both the regex and the repeated re-scanning, replacing the split(",") + collapse loop entirely:

constructor_args = []
arg_text = explicit_constructor_match.group(2)
current = []
depth = 0
i = 0

while i < len(arg_text):
    if arg_text[i : i + 2] in ("<<", "<="):  # operators, not template brackets
        current.append(arg_text[i : i + 2])
        i += 2
        continue

    char = arg_text[i]
    if char in "<(":
        depth += 1
    elif char in ">)":
        depth = max(depth - 1, 0)
    elif char == "," and not depth:
        constructor_args.append("".join(current))
        current = []
        i += 1
        continue

    current.append(char)
    i += 1

constructor_args.append("".join(current))

<<= falls out of the << branch, and clamping the decrement keeps <=> and stray > from breaking the depth count. I ran this on current develop: 206 tests pass, and it matches this PR's behavior on all four of your new cases plus the ones above.

Also worth reverting the comment rewording on line 3946 unless it was intentional as that's the other question raised in review.

The functional fix for #223 is scoped and the current checks are green: the bounds guard prevents the reported IndexError and the <-prefixed operators are no longer blindly treated as template openers.

I do not think the current head is ready while both maintainer review threads remain unresolved, though: the unrelated comment change is still unexplained, and the argument-collapse implementation still repeatedly rescans and concatenates the same text while adding a regex pass.

Please resolve those current-head maintainer threads before merge.

Reviewed current head 2e8aa7d. The functional #223 fix looks correct: I reproduced the original IndexError on the base commit and verified the <, <=, <<, and <<= cases now complete with the expected runtime/explicit behavior. Nested templates, function-call defaults, and the other comparison/shift operators I tested also behaved correctly.

I did a separate performance pass on the unresolved argument-collapse concern. On valid collapse-heavy inputs with many comma-separated template/function arguments, the current implementation remains in the same worst-case complexity class as the base code, but the added re.sub() over the growing constructor_arg produces a measurable roughly 2–3.6x slowdown in my tests. Normal-sized constructors are still fast, so this is not a functional failure, but it does confirm that the new fix adds another repeated full-string scan to an already rescan-heavy loop.

Given that this implementation concern is already unresolved in maintainer review, I don't think the current head is ready to merge yet. I don't consider the comment wording change itself a blocker; the main issue for me is resolving the repeated-rescan implementation without regressing the #223 cases.