This is still being fleshed out, but the most likely case is that the errors will be the same ones given to the Swift compiler to present as compile-time diagnostics. So there'd be a reason, a range over the input which triggered the reason, and potentially auxiliary information like a suggested fix. This can also drive pretty-printing, where the problematic range is underlined. That being said, there is a lot being proposed in this initial release so it's likely that some of these features will appear over time.
I think having some interface to access that information would be very valuable for tools taking a user-provided regex. At the very least, even if the tool is just going to fatal-error, they can present the user with a reason why their command-line invocation failed.
It certainly can be considered, but we'd likely want a throwing interface anyways. In what ways were you thinking failable would be better than try? / try!?
Argh, language. I meant to imply:
Contractions ("don't") are correctly detected and script changes are separated
"start" works for me, although we also use the term "prefix". These are the interfaces invoked by the higher-level algorithms and it would be great to align the naming scheme. There, we have trimPrefix() and starts(with:). Thoughts?
CapturedOutput seems it would have both the issues of Captures and the rather generic-sounding Output.
This distinction mostly comes up when explaining the semantic model of how concatenation of regexes work (CC @rxwei).