Skip to content

Conversation

facutuesca
Copy link
Contributor

When using the API in dynamic contexts (similarly to #531), some field types can be difficult to read when the type information is not known at compile time.

For example, Choice parsing requires the choice types to be known at compile time. By making Parser::peek_tag public, a user can check if the upcoming tag matches any of the expected Choice types, and call the appropriate method to parse it.

cc @woodruffw

@alex
Copy link
Owner

alex commented Apr 7, 2025

Can we add a direct test for peek_tag (right now its only tested indirectly via Option parsing) as well as a doc comment?

@facutuesca facutuesca force-pushed the ft/changes-for-python-lib branch from 9fa0e95 to d6ce820 Compare April 7, 2025 14:27
@facutuesca
Copy link
Contributor Author

Can we add a direct test for peek_tag (right now its only tested indirectly via Option parsing) as well as a doc comment?

done!

@alex
Copy link
Owner

alex commented Apr 7, 2025

cargo fmt -- also can you add it to the changelog in README (you can add a new [Unreleased] section). Other than that, LGTM!

@facutuesca facutuesca force-pushed the ft/changes-for-python-lib branch from d6ce820 to b73944b Compare April 7, 2025 14:29
Signed-off-by: Facundo Tuesca <facundo.tuesca@trailofbits.com>
@facutuesca facutuesca force-pushed the ft/changes-for-python-lib branch from b73944b to c1e5c78 Compare April 7, 2025 14:33
@alex alex merged commit a18dcd5 into alex:main Apr 7, 2025
12 checks passed
@facutuesca facutuesca deleted the ft/changes-for-python-lib branch April 7, 2025 14:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants