Date: Sun, 03 Sep 2023 11:50:37 -0700
On Sunday, 3 September 2023 07:39:34 PDT Jason McKesson via Std-Proposals
wrote:
> Indeed, the primary impediment of freestanding stuff like this is
> having the ability to get fine-grained requirements. That is,
> freestanding was defined by headers in pre-C++23 in an all-or-nothing
> kind of way; either everything in a header was a freestanding
> requirement or nothing was. C++20 didn't require constexpr allocator
> support to freestanding implementations because it *couldn't*, as this
> would require everything else in the allocator header to be
> freestanding requirements too. Ben Craig put forth a number of
> proposals that were all based on adding fine-grained freestanding
> requirements.
>
> And to my knowledge, nobody reacted with any pushback on the idea
> itself. Or if they did, it certainly didn't derail any of them.
Unfortunately, absence of evidence is not evidence of absence.
Which is the problem here: the community interested in freestanding C++ is
tiny, usually unable to provide said feedback in a timely fashion. This means
advancement is left to the rest of the committee whose priorities differ
substantially and thus freestanding C++ advances very, very slowly. The
solution for this is quite clear: get together and make proposals, feedback
and possibly even proofs of concept.
That their interests also often diverge is another problem (see what happened
to Contracts).
wrote:
> Indeed, the primary impediment of freestanding stuff like this is
> having the ability to get fine-grained requirements. That is,
> freestanding was defined by headers in pre-C++23 in an all-or-nothing
> kind of way; either everything in a header was a freestanding
> requirement or nothing was. C++20 didn't require constexpr allocator
> support to freestanding implementations because it *couldn't*, as this
> would require everything else in the allocator header to be
> freestanding requirements too. Ben Craig put forth a number of
> proposals that were all based on adding fine-grained freestanding
> requirements.
>
> And to my knowledge, nobody reacted with any pushback on the idea
> itself. Or if they did, it certainly didn't derail any of them.
Unfortunately, absence of evidence is not evidence of absence.
Which is the problem here: the community interested in freestanding C++ is
tiny, usually unable to provide said feedback in a timely fashion. This means
advancement is left to the rest of the committee whose priorities differ
substantially and thus freestanding C++ advances very, very slowly. The
solution for this is quite clear: get together and make proposals, feedback
and possibly even proofs of concept.
That their interests also often diverge is another problem (see what happened
to Contracts).
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-09-03 18:50:39