-
Notifications
You must be signed in to change notification settings - Fork 7
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
out_file extensions doesn't work #63
Comments
#include <seqan3/argument_parser/all.hpp>
struct parser_options
{
std::filesystem::path input{};
std::filesystem::path output{};
};
int main(int argc, char ** argv)
{
parser_options options{};
seqan3::argument_parser parser{"sharg-issue-63", argc, argv};
parser.add_positional_option(options.input, "The input file.", seqan3::input_file_validator{{"vcf", "vcf.gz", "bcf"}});
parser.add_positional_option(options.output, "The output file.", seqan3::output_file_validator{{"vcf", "vcf.gz", "bcf"}});
} gcc-11 log (click me)
|
The
As far as I remember, we (not just core, but whole team) discussed having a default, but there are pro and contra arguments for both options. Also, it seems the default in other tools/libs/... is also very mixed. However, it's a horrible error message, and very hard to see from the compiler output what's going wrong. Especially since you are right to expect the syntax to be the same for in-/ and output - but as the option needs to be set, and extensions have a default, it's not the same. How could the error be made more clear? explicit output_file_validator(std::vector<std::string> extensions) that just P.S. I like the idea of making it less chunky |
Why not just have two constructors? explicit output_file_validator(auto ... && args)
requires ((std::constructible_from<std::string_view, decltype(args)> && ...))
{
// construct from extensions; if no arguments are provided, use the default extensions
}
explicit output_file_validator(output_file_open_options, auto ... && args)
requires ((std::constructible_from<std::string_view, decltype(args)> && ...))
{
// construct from options + extensions
} This also gets rid of the |
We will discuss this in core this week or on Monday. The general problem seems that we always need a |
Core-Meeting 2022-03-15We will:
|
Thank you for discussing this and adding a better way to specify the extensions. I think a default would be nice, as typical I/O ( I also think that the current names are not very intuitive, in particular I would just go for
And avoid all talk of "opening", "creating" or "overwriting" because the argument parser does neither of these things, and any of them may or may not happen later on. But it's all not super-important 🙂 |
We did already discuss the naming en banc 😁 However, my memory failed me in some other regard: |
Oh, I searched for the wrong keywords when browsing the core meeting notes and didn't find this. |
I opened #71 I think it should address everything :) |
Nah, no point investing extra work in the SeqAn3 version if it will be replaced soon anyway! But thanks for asking! |
Does this problem persist on the current master?
Is there an existing issue for this?
Current Behavior
The first line works, the second does not.
Expected Behavior
The second line should work, too.
P.S: The
{{ ... }}
is a bit clunky. Anoperator()
with pack would be nice...Steps To Reproduce
see above
Environment
Anything else?
Issue template is fancy 🎉
P.S: I didn't try with standalone sharg-master because I didn't see any changes in the respective area.
The text was updated successfully, but these errors were encountered: