Create `Options` from iterator
LoganDark opened this issue · comments
The argv crate provides a zero-alloc way to get the process arguments. It would be really cool if I could use this with getargs without having to put the arguments in a Vec. Is this a use case you'd be willing to support?
(Side note: argv also returns &OsStr, not &str, so it's non-UTF-8 - I would have assumed getargs would work with that, but I'm not sure)
getargs doesn't work with OsStr, mostly because it would require converting to String anyway in order to parse the arguments. You should be able to use to_string_lossy then pass Cow<str>s into getargs though:
let args: Vec<_> = argv::iter().map(|s| s.to_string_lossy()).collect();
let args: Options<Cow<'static, str>> = Options::new(&args);I think supporting iterators should be possible. I might do it at some point, but honestly I don't really have the time or motivation at the moment. Feel free to fork if you're interested.
it would require converting to String anyway
Actually, it doesn't. However, the options for conversion are platform-specific and would also require the user to use cfg if they want to support multiple platforms, which is suboptimal. As-is, getargs compiles just fine on all major platforms, so any proposed change would preferably need to keep that working.
Actually, it doesn't.
I'm pretty sure it requires conversion to another string type, like &str or String. Without converting it, I don't think there's any way to access the contents of the OsStr.
Actually, it doesn't.
I'm pretty sure it requires conversion to another string type, like
&strorString. Without converting it, I don't think there's any way to access the contents of the OsStr.
It does require conversion to another type. Some of these types, like &[u8] or &[u16], do not have to be valid UTF-8 and do not trigger a UTF-8 validation. However, the former is only available on Unix and the latter is only available on Windows.
On Windows you could most likely not achieve zero-cost no-alloc without huge effort from the user.
It does require conversion to another type. Some of these types, like
&[u8]or&[u16], do not have to be valid UTF-8 and do not trigger a UTF-8 validation. However, the former is only available on Unix and the latter is only available on Windows.On Windows you could most likely not achieve zero-cost no-alloc without huge effort from the user.
Right. I would rather not have platform-specific code...
I think the easiest (and good enough) solution is just to use to_string_lossy. The user will usually want &strs anyway, and parse/FromStr only works on &strs. On Unix, the arguments will almost always be valid UTF-8 (so it almost never allocates).
Plus the user can control what to do if the argument has invalid UTF-8 -- replace the character with to_string_lossy() or panic with to_str().unwrap().
On Unix, the arguments will almost always be valid UTF-8
Almost. On Unix, file paths (which are common values for command-line flags) can be arbitrary byte seqences, containing anything except NULL. You cannot use UTF-8 to represent certain file paths. Most people don't have offending files on their systems, or can't mention them due to the invalid UTF-8, but they do exist.