*"The problem is what's not under control of the compiler, which is what
callsmain() 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.


On Mon, Sep 9, 2024 at 5:41 PM Thiago Macieira <thiago_at_[hidden]> wrote:

> On Monday 9 September 2024 13:30:37 GMT-7 Jarrad Waterloo wrote:
> > > "there's only *one* main signature."
> > some programmers would argue that there are multiple signatures now, see
> the
> > following
> >
> > https://en.cppreference.com/w/cpp/language/main_function
> > see 1, 2 and 3
> > 6.9.3.1 main function
> > Concerning #3 according to working draft 6.9.3.1
> > "Recommended practice: Any further (optional) parameters should be added
> > after argv"
>
> Please use proper quoting and please keep the mailing list in Cc, or reply
> only to the mailing list.
>
> I understand that that's what programmers think when they see that. That's
> not
> the problem.
>
> The problem is that, from the point of view of the implementation, there's
> only *one* main: it's called "main", returns int and takes three
> parameters:
> one int and two char** arrays. That's it. That's how it is implemented,
> it's
> called from exactly one place, always the same way.
>
> > This doesn't even include the C variations and whether the function has
> to
> > return int or just void.
> > https://en.cppreference.com/w/c/language/main_function
> > If the return type of the main function is not compatible with int (e.g.
> > void main(void)), the value returned to the host environment is
> > unspecified. If the return type is compatible with int and control
> reaches
> > the terminating }, the value returned to the environment is the same as
> if
> > executing return 0;. since C99
>
> That's just the compiler emitting a "return 0" where you didn't. That's
> again
> not the problem. All this is under the control of the compiler.
>
> The problem is what's not under control of the compiler, which is what
> calls
> main() in the first place.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
>