My dream is named captures via let bindings inside the result builder, allowing you to interact with them later in the builder as a kind of Swift take on backreferences. Something like monadic bind would allow you to accumulate and forward values (though I don't know enough about result builder design rationale to know whether this is sacrilege).
The direct way would be by calling Collection.distance() with the returned indices. We could expose a method on the match result to calculate that for you.
We're unlikely to eagerly track the count during matching, as we'd rather operate directly over the UTF-8 bytes whenever possible without having to run grapheme-breaking for everything.
I definitely do want to talk about them! But that's a much longer reply that I'm drafting.
As outlined, the result of a match would be some kind of match object containing information about the overall match alongside captures, so you'd have to stick a .captures on the end.
That being said, I'm a big fan of allowing types to define custom tuple destructuring, so it's possible that statement would work as-is. It does open the door to ad-hoc type relationships when you can't just parameterize over a generic, but no more so than destructing matching or even collection algorithms.
I expect there to be a lot of pressure on the final design to eliminate such boilerplate, so it's good to be talking about, and identifying, ad hoc type relationships now.
Right, API design might obviate concerns about the return type.