Adds SpanSplitEnumerator

[bbartels]

Implements #934

TODO:

• Add SplitAny tests
• Add SearchValues tests
• Add documentation for public API

IEquatable<T> type constraint is necessary due to the type constraint existing on the System.MemoryExtensions.IndexOf<T>() overloads and on SearchValues<T>.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[stephentoub]

@bbartels, please let us know when this is ready for review.

[bbartels]

@bbartels, please let us know when this is ready for review.

Will do, will finish off over the weekend!

[stephentoub]

Ok, thanks

[bbartels]

@stephentoub ready for review 🙂

[stephentoub]

Thanks. Given the time pressure, I'm making changes in a commit locally which I'll push to your branch for you to explore.

[stephentoub]

Done. @bbartels, please take a look. Most important changes:

• Changed SplitAny to treat an empty char separators as do string.Split and the existing MemoryExtensions.SplitAny, where it means any Unicode whitespace
• Reduced overheads in MoveNext by removing some unnecessary branches and Slice.

[bbartels]

Changed SplitAny to treat an empty char separators as do string.Split and the existing MemoryExtensions.SplitAny, where it means any Unicode whitespace

Was this discussed in api review? I have no recollection. I could see that being rather concerning behaviour special casing this for a single type.

[stephentoub]

Was this discussed in api review? I have no recollection. I could see that being rather concerning behaviour special casing this for a single type.

I believe it's implied by these APIs behaving the same as the other overloads. I think it's more concerning that you'd switch from strings to spans and your use silently behaves differently.

If we really don't like the discrepancy, we should change these to be specific to char rather than T. But then keep in mind that if we ever added T-based overloads, you'd still have the exact same difference in behavior when specifying char vs other types, binding to one overload with one behavior vs the other with the other. (Also various APIs for spans already special-case char, e.g. span.ToString).

[bbartels]

Was this discussed in api review? I have no recollection. I could see that being rather concerning behaviour special casing this for a single type.

I believe it's implied by these APIs behaving the same as the other overloads. I think it's more concerning that you'd switch from strings to spans and your use silently behaves differently.

If we really don't like the discrepancy, we should change these to be specific to char rather than T. But then keep in mind that if we ever added T-based overloads, you'd still have the exact same difference in behavior when specifying char vs other types, binding to one overload with one behavior vs the other with the other. (Also various APIs for spans already special-case char, e.g. span.ToString).

Fair point, I guess there is realistically no way around just supporting this quirk in some way.
Thanks for the review, let me have another look over to see if there is anything to spot. Otherwise let's get this (finally) merged 😄

[bbartels]

@stephentoub I've had another look into simplifying things a little. Came up with this: https://github.com/bbartels/runtime/pull/1/files. Thoughts?
Upside:

• Less work per iteration
• Smaller struct

Downside:

• Could be considered slightly more convoluted
• Call to SpanSplitEnumerator.Current will throw if MoveNext() has not been called yet.
  The throwing should be fine under the IEnumerator.Current contract:
  

[stephentoub]

Thoughts?

We could. I have a small preference for what's currently in this PR just because I think it's a bit easier to understand.

[bbartels]

We could. I have a small preference for what's currently in this PR just because I think it's a bit easier to understand.

Alright, up to you, I trust your judgement! Otherwise lgtm from my perspective

[stephentoub]

Thanks, @bbartels.