Why even talk about stack or heap allocation, when we can just as well
allow a lazy evaluation if performance is a concern. I.e. we can create a
"simple to write" type that essentially wraps:
```c++
// Not sure if transform takes ownership of the input span here, but you
get what I am trying to do at least...
std::views::transform(std::span(argv, argc), [] (char* ptr) { return
std::string_view(ptr); });
```
.
We could essentially create a `std::terminal_arguments`-type that just
wraps the aforementioned code. We could even make it somewhat compatible
with legacy code by allowing access to the underlying pointer and reducing
the argv (increasing it would be UB...).

// Robin

On Tue, Sep 10, 2024 at 2:56 PM Jarrad Waterloo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
> *"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
>>
>>
>>
>> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>