-
Notifications
You must be signed in to change notification settings - Fork 21
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
API enhancement #3
Comments
To turn a string into a cstring. You need to append a null byte to the end. If you pass in a String then you can take ownership of it and just append the byte. If the function took in a str, then you'd have still have to allocate a buffer so you can append a byte to it. This is why I went for String. The actual cstring API takes in a For the second point, do you mean things like, description and URL? In that case, I'm not really sure what to do. I tried to make this API stick as closely to alpm as possible. And in alpm, if desc is empty, the function But I don't think I'm really against changing it, as long as it's consistent and doesn't make the API too annoying to use with options everywhere. |
For Path specifically, it's even worse. As Path is backed by OsString, the actual data stored is OS dependant, and the alpm functions expect a regular |
OK, maybe it's more tricky than I thought. This is just because I use I will probably use For the second point, I think it's always easier with options given that you can do E.g., I want to return an error when the architecture field is missing. In this situation I could do: let arch = pkg.arch().ok_or(MyErrorType::MissingField)?; Or if I want the same behaviour as now: let arch = pkg.arch().unwrap_or(""); |
I'm fine with making arch, desc, etc Options. With the path stuff. The reason you howe to call . display() and can't just convert it to a string is that a path may contain not unicode so the conversion is lossy. Thin is fine for displaying. But if you actually want to use the file then it may end up opening a different fine. Even if the chances are very low. |
OK! I'll do the modification ASAP. |
Hi,
In order to improve the API, I suggest to apply these modifications to the crate :
<S: Into<String>>
with<P: AsRef<Path>>
for path typed arguments (given that we can still use &str).&str
(and "" if missing) forOption<&str>
(and None if missing).If you want, I can do the modification in a PR.
The text was updated successfully, but these errors were encountered: