Result Iterators #44
Draft
Result Iterators #44
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a draft of changes I would like to make in order to add an API to iterate through results in a more "ergonomic" way. Due to the constraints of the iterator not actually producing elements, I could not implement
Iterator<Item = SomeResult>for the elements of the iterator (unless I'm missing something obvious this would have to be done with a streaming iterator) but I settled on a strongly typednext()function that produces a strongly typed result.I'm not entirely a fan of this interface, and there are unresolved questions about what bounds should look like wrt things like getting all textlines in a single block, or getting all characters in a textline or what have you, but I figured this was good enough for at least a look.
In making some of these changes, I also migrated the integration tests to
tests/over having them be in-file. I'm fine with moving it back in the file, but feel that doctests or similar are more deserving of being in-file.The result types are strongly typed, and I have some more prototyping to do around getting textlines in a block type thing but those are less design-type issues.