"The problem is what's not under control of the compiler, which is what calls
main() in the first place."
This is where the breakdown in communication is.
Those who want "int main(const std::span<const std::string_view> args)" are not asking for what calls main to change at all.
What is being asked is the following:
#1 The programmer is able to define a main function of the following signature and future signatures.
int main(const std::span<const std::string_view> args)
#2 When the compiler sees the above signature it adds the following stub/bridge.
int main(int argc, char *argv[])
{
std::vector<std::string_view> args;
args.reserve(argc);
for (int ndx{}; ndx != argc; ++ndx)
args.push_back(argv[ndx]);
return main_alt(args);
}
OR if the maximum number of arguments is told to the compiler than the following
int main(int argc, char *argv[])
{
constexpr int MAX_SIZE = 32;
std::array<std::string_view, MAX_SIZE> args;
int size = std::min(argc, MAX_SIZE);
for (int ndx{}; ndx != size; ++ndx)
args[ndx] = argv[ndx];
return main_alt(std::span<const std::string_view>{args.begin(), (size_t)size});
}
OR use C++26's inplace_vector
OR the compiler uses C's VLA or alloca.
See, not complicated at all and doesn't even touch that which calls main.
Rather, what is asked for IS of the compiler and consequently within the purview of the standards body.
...
Now let' talk about performance.
"I've already explained that creating a span of string_views MAY be prohibitively expensive in terms of memory consumption and time. That idea is DOA."
[bold and uppercase added]
It's shocking that DOA is liberally applied on a MAYBE!
That doesn't change the following facts.
A) It doesn't break existing code.
B) It's zero cost in the sense that it doesn't cost you anything if you don't use it.
C) There doesn't even have to be a dynamic allocation for those programs that can't have it, if maximum argument configuration is provided to the compiler or if VLA or stackalloc is used.
So, why do past code and past programmers needlessly demand that future code and future programmers can't exist. The future is not demanding that the legacy main shouldn't exist. Show like courtesy.
Further, what do you do in a more safety conscious world such as if ever borrow checking gets adopted which requires std2 which will want to check even legacy main?
Must we keep kicking the alternate main problem and the safety problems down the road.
It's embarrassing.
This is on top of the fact that the standard does mention multiple signatures, and compiler(s) already provide additional ones.
This rationale also works for the character type variations of the debate and also future signatures needed for either library versioning or safety reasons.