-
-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
glib: Implement Regex #947
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me otherwise, thanks!
Not a blocker, but it would be good if eventually we could have a documentation note here saying this should not really be used by Rust programs except for compatibility reasons. No one should ever be writing new code with this unless necessary, e.g. calling those libgranite APIs that need it. There are much better native Rust implementations, even the pcre2 crate is better than using this. Edit: some more background here https://gitlab.gnome.org/GNOME/glib/-/issues/1085#note_1270415 |
7ed6f30
to
3d5d166
Compare
Would you mind rebasing this one? |
4acef6e
to
66536c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
otherwise lgtm
Looks good to me apart from those trivial things. Once that's all covered, can you squash the commits together? |
Thank you both for the feedback, I'll work on addressing the last few comments over the next few hours. But first, a question: It looks like I initially manually implemented a lot of these methods so we could use Is it still the case that it would be preferred to have manually written bindings just to get |
Keep them like this until gir supports generating them like this. That's what the comment in |
These modules are inefficient and should not be used by Rust programs except for compatibility with GLib.Regex based APIs. All methods are implemented except for g_regex_replace_eval
5db46b3
to
ac892d2
Compare
I have resolved all feedback apart from the non-blocking comment about the missing implementation of Thanks again for your reviews, let me know if there's anything else I can do here. |
Looks good enough, we can always iterate later if needed. Thank you for your contribution |
This has some soundness issues, see #1223 |
I'm interested in generating bindings for https://github.com/elementary/granite which exposes GLib.Regex as part of its public API, so it would be good to have these in the
glib
crate to depend on.