-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Consider accepting a Cow instead of Into<&'b str> in App::about #2150
Comments
Related: #1728 |
@d-e-s-o Do you think you can take a small attempt at this by only changing the |
This is related to my proposed fix for #1041 |
A challenge is Calling with |
I dislike the inconsistency with only a few fields providing this (this and `help_heading`) but this is to address a specific bug. We need to visit this, along with iterators (clap-rs#2870) and string handling (clap-rs#2150). `Arg` came along for the ride because the derive logic is applied to both. `PossibleValue` didn't need it because we filter out `long_help`. BREAKING CHANGE: We changed the signatures for `App::about`, `App::long_about`, `Arg::help`, and `Arg::long_help` from accepting anything `Into<&str>` to `&str`.
I dislike the inconsistency with only a few fields providing this (this and `help_heading`) but this is to address a specific bug. We need to visit this, along with iterators (clap-rs#2870) and string handling (clap-rs#2150). `Arg` came along for the ride because the derive logic is applied to both. `PossibleValue` didn't need it because we filter out `long_help`. BREAKING CHANGE: We changed the signatures for `App::about`, `App::long_about`, `Arg::help`, and `Arg::long_help` from accepting anything `Into<&str>` to `&str`.
I dislike the inconsistency with only a few fields providing this (this and `help_heading`) but this is to address a specific bug. We need to visit this, along with iterators (clap-rs#2870) and string handling (clap-rs#2150). `Arg` came along for the ride because the derive logic is applied to both. `PossibleValue` didn't need it because we filter out `long_help`. BREAKING CHANGE: We changed the signatures for `App::about`, `App::long_about`, `Arg::help`, and `Arg::long_help` from accepting anything `Into<&str>` to `&str`.
Impact: - Binary size: 556.6 KiB to 578.4 KiB - build time: 6.4950 us (7% slower) - parse time: 7.7256 us - parse sc time: 8.1580 us (5% faster) Fixes clap-rs#1041 Fixes clap-rs#2150
Impact: - Binary size: 556.6 KiB to 578.4 KiB - build time: 6.4950 us (7% slower) - parse time: 7.7256 us - parse sc time: 8.1580 us (5% faster) Fixes clap-rs#1041 Fixes clap-rs#2150
I find the signature of methods like
App::about
not super useful. It's probably fine when doing everything statically, because you could easily make sure that the string provided outlives theApp
object (because most of the time you have a 'static string anyway as everything is defined statically in the code). But consider the case where you'd want to add subcommands dynamically at runtime. It gets unnecessarily unwieldy now, in my opinion, because of the lifetime requirement.Couldn't you instead accept a
Cow<'b, str>
? This way, users that do something more dynamic would at least have the possibility to fudge that with a dynamic memory allocation at the call site, instead of doing some dance to make the generated string outlive theApp
object or even boxing the string up just to leak it.The text was updated successfully, but these errors were encountered: