[SUGGESTION] Support for a "`main` v2" signature

[aslilac]

The usual argc/argv signature requires familiarity some C idioms that don't really have broad influence on C++. An alternative signature could allow new learners to not be bogged down by the dubious char** and \0 termination, and would instead provide them with a clearer, more familiar data type, that would be less error and abuse-prone. Ideally it would only take a single argument, args, which would be a standard list container, holding some number of arguments. Perhaps main : (args: std::vector<std::string_view>) -> int.

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?

I've seen some wild forms of argument parsing out there that abuse argc. The percentage would definitely be small, but I'm sure there are people out there misusing argc enough to have allowed a memory safety bugs to slip in.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?

It's largely agreed that passing a length and a C array is bad practice when writing your own functions, but you don't get to dictate the signature of main. Requiring main to follow an idiom that is otherwise frowned upon (and in a place that every C++ programmer is bound to come across!) raises a lot of questions about why things are this way, and why it's a bad idea to use a signature like main's elsewhere in your code. If main took something a little more idiomatic, those conversations can be kicked down the road until much later, instead of requiring they be addressed while trying to write a "Hello, world!"

Some references:

• Jason Turner recently did a whole video that basically ended with the advice "you should probably be constructing a std::vector<std::string_view> immediately, and then only using that.
• The SerenityOS project has a header file which can be included in any individual program that lets you write a serenity_main function with a nicer type signature, instead of writing the usual main function.

Describe alternatives you've considered.
Some potential types that could be used for args

• std::array<_>
• std::vector<_>
• _<std::string>
• _<std::string_view>

[hsutter]

Thanks, and thanks again to everyone else who has made this suggestion in past issues. This has been on my mind as well.

Yes, there's a safety aspect to this. Just as importantly, there's a simplicity aspect: Simplifying C++ includes addressing the things, even little things, that are constant annoyances and sources of friction and just distractions because we keep having to talk about them (and in many but not all cases have to teach them). That this keeps coming up shows that this is one of those things.

I've already started implementing this a couple of times, and backed it out only because string_view isn't guaranteed to be null-terminated. But I don't think that should hold this back anymore... after all, these string_views will be null-terminated because of how we got them.

With the above checkin, the following works:

main: (args) = {
    for args do :(arg) =
        std::cout << arg << "\n";
}

There can now be a single-parameter form of global main that defaults to deduced type (you can write : _ but you don't have to), and the type will be deduced to vector<string_view>. You can name the parameter whatever you want, but I like args... :)

If the programmer tries to write something like main: (inout x) or main: (x: int), they'll get this error:

error: when 'main' has a single parameter, that parameter should be declared as just:  main: (x)  - the type 'std::vector<std::string_view>' will be deduced

Thanks again, everyone!

[aslilac]

Sorry for the duplicate! I tried to search for if someone had already suggested this and must've missed it! But very happy to see this change. :) Thanks Herb!

[filipsajdak]

@hsutter, one question regarding the new main() syntax there are libraries that expect to process argc and argv arguments, e.g., command line options parsers. In my project I am using cxxopts and previously the following code worked:

main: (argc:int, argv:**char) -> int = {

    options : cxxopts::Options = ("execspec", "Executable specification - create docs that test your code");

    options.add_options()
        ("i,input",  "Input markdown",   cxxopts::value<std::string>())
        ("o,output", "Save output to",   cxxopts::value<std::string>())
        ("d,debug",  "Enable debugging", cxxopts::value<bool>()*.default_value("false"))
        ("html",     "Generate html",    cxxopts::value<bool>()*.default_value("false"))
        ("h,help",   "Print usage");

    result := options.parse(argc, argv); // <----- here the lib uses argc & argv... and have no other methods available

    if result.count("help") {
      std::cout << options.help() << std::endl;
      exit(0);
    }
// ...
}

Maybe we should provide a way to get argc & argv for some cases? I think it should not be the default, but for the sake of

backward source compatibility always available

I think we should provide it.

I am asking here to clarify if I should post a bug report or if is it a feature that I need to learn to live with.

[filipsajdak]

I have realized that I can rewrite it to:

main: (args) -> int = {
// ...
    result := options.parse(argc, argv); // <---- argc & argv are available on the cpp1 side as implementation detail
// ...
}

It will generate the following cpp1 code:

[[nodiscard]] auto main(int argc, char **argv) -> int{
    auto args = cpp2::args(argc, argv); 
// ...
    auto result {CPP2_UFCS(parse, options, argc, argv)}; 
// ...
}

The question is if using implementation details is the solution we want to support.

[hsutter]

That's a good point...

The named parameter args gives you easy access to the value of argc by asking args.ssize(), but not to argv if you really really want an array of raw pointers.

But because under the covers cppfront generates the standard signature, you actually do have access to both argc and argv directly with those names. So this works right now:

main: (args) =
    std::cout << "argc is (argc)$, and argv[0] is (argv[0])$\n";

That said, I didn't actually realize that until you asked the question, so thanks! And I like it... it encourages the right thing (the visible named parameter is safe and the thing you naturally use), but writing a named parameter also makes argc and argv implicitly available and that strikes me as a useful convenience (i.e., a feature, not a bug). Bonus: And they are guaranteed to have those familiar names, whereas today those two parameters can be called whatever the programmer wants to name them, those names are just a convention today.

Speaking of which... one thing that I haven't done, but have sometimes considered, is requiring the name of the single parameter to actually be args (right now you can name it anything). Requiring it to be the name args removes a degree of freedom, but one that doesn't matter, so it arguably could be a "constraints are liberating" benefit in the sense of directing creativity toward the directions that matter, and it would guarantee the visual consistency (args, argc, argv).

[hsutter]

Ah, racing replies -- you saw it too. Yes, I think it's important to guarantee those names' availability because you gave a great motivating example showing that it's part of full compatibility with all existing C and C++ libraries, which rely on argc and argv.

What do you think of requiring the single-main-parameter name to be args?

[filipsajdak]

Most of us were using argc and argv by convention. My first choice, nevertheless, would be args. So, from that point of view, requiring the name to be exactly args should not harm and would be aligned with what most of us will do. That will reduce complexity by reducing name variation.

[JohelEGP]

I like the idea of making argc and argv available.

Instead of a std::vector of std::string_views for args, have you considered using a std::ranges::view, like lefticus/cpp_weekly#255? Perhaps even a new type, model of std::ranges::view, with accessors to the values of argc and argv. Then those names don't have to be available so as to not make main more special. Accessors like size and array-for-argv could be more readable than 3 similarly named variables.

It looks like the code at #262 (comment) would generate an unused args warning. If argc and argv are available, it'd make sense to make args [[maybe_unused]].

[filipsajdak]

Last quick thought before going to sleep. Maybe we can do something like this: https://godbolt.org/z/s7bq33MT7

struct Args : std::vector<std::string_view> {
    Args(int c, char **v) : vector{(size_t)c}, argc{c}, argv{v} {}
    int argc = 0;
    char** argv = nullptr;
};

inline auto args(int argc, char **argv) -> Args {
    auto ret = Args{argc, argv};
    for (auto i = 0; i < argc; ++i) {
        ret[i] = std::string_view{argv[i]};
    }
    return ret;
}

args will behave like before but will give access to argc & argv without hiding them in implementation details.

[filipsajdak]

Array requires the size to be known at compile time which is not the case for the main() function.

[AbhinavK00]

Sorry for my replies, realised they weren't correct so deleted both of them.

[hsutter]

@filipsajdak I like your implementation strategy, and I'll pursue the direction of providing args.argc and args.argv, and deliberately uglifying the actual main parameter names so that they shouldn't be used directly. Thanks!

(Fun fact: Generating the main parameter name __argc causes MSVC to generate an executable that crashes when you try to use that name to access the int. That's what can happen when you stray into the implementer's namespace... so I'll use something like argc_ and argv_ as the uglified names instead.)