Date: Tue, 22 Jul 2025 21:58:07 +0200
Hey Arthur,
Keep in mind that the proposal is a very early draft. Just a bit of
Markdown snippet to have something for [std-proposals], really. I
would have absolutely included such a comparison table in the
proposal.
As Brian said, I don't think there's merit in unsigned main(); it's exotic.
Also, addressing everyone:
I was hoping that the reactions on [std-proposals] would be more
positive, but as they aren't, I'm not confident that this proposal is
worth committee time. It seems like if you just take the const
correctness fixes for argv, probably everyone would agree they improve
the status quo, but they're also a bit inconsequential, and we can
live with the status quo of "works everywhere, even if not standard".
Once you add more ideas to the proposal, like "void main" and "envp",
opinions become torn, and this looks to be a long, low-consensus
debate over a change with little practical benefit. It's a dichotomy
between "not enough value" and "not enough consensus", and I cannot
find any sweet spot.
Anyhow, I guess I'm stepping away from the idea then, but thanks for
all the feedback.
Jan
On Tue, 22 Jul 2025 at 21:31, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>
> On Tue, Jul 22, 2025 at 12:34 PM Brian Bi via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tue, Jul 22, 2025 at 12:24 PM Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> Finally, it must be taught that it is unconventional and not supported by older compilers.
>>
>>
>> "not supported by older compilers" could be raised as an argument against literally any new feature.
>
>
> And it specifically should not be used against this feature, because IIUC the entire point of this feature is that every old compiler already supports it.
> I'm all in favor of standardizing existing practice. However, @Jan, your paper is conspicuously missing a table demonstrating which signatures are actually supported by the Big Four compiler vendors (and since what release/year they've been supported).
>
> You mention that you don't propose to standardize signatures containing `volatile`. I think that's the right choice; but again, you're missing a table demonstrating whether such signatures are already supported in practice.
>
> I recommend not trying to standardize `void main()` for two reasons:
> (1) Returning `void` instead of `int` actually could require different prologue/epilogue codegen on certain platforms. (Adding `const`-qualification to a pointer definitely doesn't.)
> (2) There is a very large body of work devoted to making fun of people who write `void main` and/or telling learners that `void main` is an even worse solecism than `using namespace std`. (Probably a significant fraction of this body of work was generated by current WG21 members, too.) You'd be proposing to obsolete all of that advice and horribly confuse newbies for decades to come. That's not just "not worth" doing; it's worth positively not doing.
>
> I wonder whether there is any prior art for
> - `unsigned main()` — this is certainly a physically compatible signature on all platforms, but does any compiler support it today?
> - `uint8_t main()` — I'm less sure this is physically compatible (same as my first objection to `void main`), but it logically more closely matches how Linux treats the return code. Does any compiler support it today?
>
> my $.02,
> –Arthur
Keep in mind that the proposal is a very early draft. Just a bit of
Markdown snippet to have something for [std-proposals], really. I
would have absolutely included such a comparison table in the
proposal.
As Brian said, I don't think there's merit in unsigned main(); it's exotic.
Also, addressing everyone:
I was hoping that the reactions on [std-proposals] would be more
positive, but as they aren't, I'm not confident that this proposal is
worth committee time. It seems like if you just take the const
correctness fixes for argv, probably everyone would agree they improve
the status quo, but they're also a bit inconsequential, and we can
live with the status quo of "works everywhere, even if not standard".
Once you add more ideas to the proposal, like "void main" and "envp",
opinions become torn, and this looks to be a long, low-consensus
debate over a change with little practical benefit. It's a dichotomy
between "not enough value" and "not enough consensus", and I cannot
find any sweet spot.
Anyhow, I guess I'm stepping away from the idea then, but thanks for
all the feedback.
Jan
On Tue, 22 Jul 2025 at 21:31, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>
> On Tue, Jul 22, 2025 at 12:34 PM Brian Bi via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Tue, Jul 22, 2025 at 12:24 PM Paul Caprioli via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>>
>>> Finally, it must be taught that it is unconventional and not supported by older compilers.
>>
>>
>> "not supported by older compilers" could be raised as an argument against literally any new feature.
>
>
> And it specifically should not be used against this feature, because IIUC the entire point of this feature is that every old compiler already supports it.
> I'm all in favor of standardizing existing practice. However, @Jan, your paper is conspicuously missing a table demonstrating which signatures are actually supported by the Big Four compiler vendors (and since what release/year they've been supported).
>
> You mention that you don't propose to standardize signatures containing `volatile`. I think that's the right choice; but again, you're missing a table demonstrating whether such signatures are already supported in practice.
>
> I recommend not trying to standardize `void main()` for two reasons:
> (1) Returning `void` instead of `int` actually could require different prologue/epilogue codegen on certain platforms. (Adding `const`-qualification to a pointer definitely doesn't.)
> (2) There is a very large body of work devoted to making fun of people who write `void main` and/or telling learners that `void main` is an even worse solecism than `using namespace std`. (Probably a significant fraction of this body of work was generated by current WG21 members, too.) You'd be proposing to obsolete all of that advice and horribly confuse newbies for decades to come. That's not just "not worth" doing; it's worth positively not doing.
>
> I wonder whether there is any prior art for
> - `unsigned main()` — this is certainly a physically compatible signature on all platforms, but does any compiler support it today?
> - `uint8_t main()` — I'm less sure this is physically compatible (same as my first objection to `void main`), but it logically more closely matches how Linux treats the return code. Does any compiler support it today?
>
> my $.02,
> –Arthur
Received on 2025-07-22 19:58:25