'index' and 'input' property on return type for custom token pattern

The return type for a CustomPatternMatcherFunc is a RegExpExecArray (or null), which is defined as:

interface RegExpExecArray extends Array<string> {
    index: number;
    input: string;
}

The documentation doesn’t mention these properties. Are they actually required? If so, what should their value be? If not, perhaps RegExpMatchArray would be a better return type? It’s the same as RegExpExecArray but with the index and input properties marked as optional:

interface RegExpMatchArray extends Array<string> {
    index?: number;
    input?: string;
}

[bd82]

That’s really clever… Does it hurt maintainability like at all? The performance benefits are obviously worth it but I’m curious how such a thing impacts debugging/maintenance.

I think I’ve read about this “NOOP” pattern in a performance guide related to BlueBird promises library…

It can hurt maintainability by adding complexity and even some partially duplicated code, also sometimes there are performance regressions in V8 that need to be tracked down and mitigated. e.g: https://github.com/SAP/chevrotain/issues/942

Basically Performance is a feature and every feature has its costs 😦

[HoldYourWaffle]

Whoops I completely missed your other comment…

Basically this.attemptInRepetitionRecovery method is defined either as NOOP (empty function) or the “real” function with the logic, depending if the parser uses the recovery feature. So if the recovery feature is not used, an empty function would get in-lined when V8 optimizes the hotspot and the result of in-lining an empty function is “nothing” so there is no runtime cost for the optional feature… Does this make sense?

That’s really clever… Does it hurt maintainability like at all? The performance benefits are obviously worth it but I’m curious how such a thing impacts debugging/maintenance.