Hi Everyone,

     Just following up here. I put out initial feelers into the GCC
and Clang communities here
(https://gcc.gnu.org/pipermail/gcc/2025-June/246133.html) and here
(https://discourse.llvm.org/t/prepreocessor-embed-parameter-ordering/86724).
There's some appetite to try the change, but no strong affirmative
push for it to be mandated or part of the standard.

     I think a good first step for P3731r0, before discussion, would
be for me to trial it by submitting patches for warnings to GCC and/or
Clang. If it gains steam and has positive reception (i.e., nobody
complains loudly about it IF the patches are accepted), then I think
standardization would be appropriate. But, as it stands now, I don't
think carrying this forward into the C or C++ standards is merited
right now (and therefore I won't really be submitting P3731r0 into the
mailing just yet, as it doesn't look like it'll have enough support to
go anywhere).

     Therefore, I'm going to move ahead with P3540r2 in C++, as well
as the synchronization paper for WG14.

Sincerely,
JeanHeyd


On Thu, Jun 5, 2025 at 8:46 PM JeanHeyd Meneide <phdofthehouse_at_[hidden]> wrote:
>
> Hi Everyone,
>
> Thank you for the discussion on P3540r1 (and its upcoming
> version, P3540r2). r2 has had the one typo fix changed from "It shall
> provide" to "it provides" in the wording, and should be ready for
> EWG/Core review: https://isocpp.org/files/papers/P3540R2.html
>
> As pointed out at the end of the discussion, there was some
> questions about adding a new feature/constraint related to the
> parameters. Some people wanted constraints/ill-formed diagnostics for
> if "offset" appeared before "limit", while someone else pointed out
> that this should also apply for "if_empty", "suffix", and "prefix"
> since they are dependent on whether the resource is considered empty
> (which e.g. offset(SIZE_MAX) or limit(0) could provoke).
>
> Those discussion points are captured in a new paper here:
> https://isocpp.org/files/papers/P3731R0.html
>
> As stated in the paper, I have no opinion on this and personally
> do not think it's necessary. The Committees and Subgroups can decide
> how far this goes / what they want out of it. I will also publish a
> separate paper for C, too, and keep both in sync as they travel
> through the Committees with the various feedback from the groups about
> ordering concerns. I also plan to talk to the implementers VIA
> e-mail/discourse.
>
> Sincerely,
> JeanHeyd