Done.

:D

Then someone would invent the floatiest floaty zero ever.

Thank you for the constructive feedback! I've had some struggles deciding how best to handle return points in conditional-based functions, reframing it as "what output do I want?" makes a lot of sense.

I can at least say that user-input regex is not for prod on account of they can be used for denial of service attacks, though Python's regex engine seems to be capable of running system interrupts if a regular expression is taking too long (the use of goto statements makes this very hard to analyze). I'm not so sure about Javascript being able to be interrupted so that'd be something to look into if you're thinking user-defined regex.

The criticisms here aren't about using regular expressions, but how long the regular expression takes to execute compared to an alternative solution that doesn't use regular expressions, so it's always going to be slower than that particular alternative solution, but the inherent increase in slowness is limited by the data it's being applied too. So if you're running it on very large strings or a lot of strings it's going to be much slower (O(n^2)) as the string size increases, but if the amount of data you're applying it to is small/infrequent, the increased slowness is negligible.

So from the time complexity side of things, the faster solution is better. And computer science programmers are usually taught about time complexity, though there's also another dimension called space complexity that often gets overlooked which this solution performs better on than the faster solution (uses fewer system memory resources).

And from the practical application side of things, it suffices in certain but not all contexts because you've obviously got trade offs on what resources are available (processing time available vs. space available in system memory).

just for understanding,
regex is not for prod,
or greedy regex is not for prod,
or it depends,
or if don't know/sure, then don't use regex on prod?

Could you elaborate on how this could be improved? (Or I'm missing the point of your feedback)

Your example is not proper. The list may be [1, 2, 4] for you, and you can easily find the answer is [1, 2, 3, 4], now you also can know there are "list.length" intervals and "The missing term will never be the first or last one." So the step is "(list[list.length - 1] - list[0]) / (list.length)". Sorry, my poor English...I hope you can understand what I say.

Whether to use this in production code depends on the scope of the problem. If it's a one-off and the execution time only needs to be reasonable, this will work. If you're doing this operation on lots of different strings, then sorting them all is unnecessary overhead on execution time.

On the other hand, the general approach works well with memory management, but for better memory performance, you'd want to iterate the regular expression instead of storing all the duplicates as captures. If you for some reason want knowledge of the duplicates themselves, which goes beyond the scope of the requirements, then this method makes sense for memory management, but again that goes beyond the scope of the requirements of this particular function.

I'm not sure about performance...
Also, it seems to be widely used and work anywhere, but does [^] have a documented behavior?

or you could also have changed n**2 to n*n which will be right and one char shorter