+1 for no one wants to deal with that regex. But I imagine plenty of people wondered how it would be done.

Cool solution! But is it O(n^2) compared to O(n) for the stack approach?

Thank you this code is very helpful specially on String manipulation.
I have learned that in the split method I can use regex on it and The \G

Yeah, this is quite clever. And if you know regex, you can kind-of understand at the first glance what's going on.

But wouldn't want to have it production. :D

My solution is muuuuuch worse, and not even close to being as cool as this one.

Hi pretty cool,

what i have to mention is, what exactly are you doing if
the use case changes and you would have to compute any string within any valid braces?

To add on, I think it's also because the pair of brackets will only be replaced with "" if the open and close brackets are in the correct order, of the same type as well as next to each other, on each iteration. By the last iteration, it should give you a "" if the bracket orderings are valid.

1. the code is very concise - that is good
2. readability is not very good due to the mysterious regexp
3. regarding productivity: I've tested a simple code execution in a loop (100000 times) and compared results with my implementation and it is almost 10 times slower (320 ms vs 43 ms) - and that is bad (most porbably either due to String.split complex implementation or because it compiles RegExp object on every call)

This is a really smart solution. Impressive.

Bad code.

Cool solution an much better than my own, but in no way is that "best practice".

just wow :)

nice

I agree, my first thought was to include non-english characters.

I wonder if regexes are considered "best practice" when there is a comparably easy to read for loop based answer?