Date: Thu, 9 Nov 2023 22:09:55 +0200
On Thu, 9 Nov 2023 at 21:58, Tom Honermann via SG21
<sg21_at_[hidden]> wrote:
>
> Cross-posting to SG15 and SG21.
>
> My goal with this email is to encourage collaboration between SG21 (Contracts) and SG15 (Tooling) on the contracts MVP well in advance of the design being presented and potentially approved by EWG.
The goal is fine, it's great. Some nitpicks follow.
> Some regular attendees of SG15 have expressed concerns that a contracts design (the MVP) might be accepted for C++26 without adequate tooling consideration thereby potentially leading to a situation like we have now with modules where we have a language feature with significant adoption challenges. I share some of these concerns.
I would hesitate to suggest or leave room for the impression that
modules were standardized without adequate tooling consideration.
Furthermore, some new language facilities just do have adoption
challenges, that's sometimes the nature of the beast. The
tooling-feedback
from e.g. build system developers hasn't thus far revealed a need to
do major design surgery to modules, as far as I have understood.
Keeping tooling people up to date is always a good idea, of course.
> Such use will be constrained for applications that have dependencies on packages provided by package managers. Package managers are unlikely to provide separate contract-disabled and contract-enabled builds, nor are system package managers likely to provide multiple builds (they don't provide separate assert-disabled and assert-enabled builds today for example).
Have you checked the validity of these predictions with system package managers?
> Use in production will require means to provide packages that, at run-time, can have any of the contract semantics (ignore, observe, enforce) enabled at load-time. This capability would require very low overhead means to enable such selection at load-time. Existing linker technologies like the GNU ifunc extension to ELF might pave the way to low overhead solutions.
..because this seems to take some of those predictions for granted,
and then seems to jump to conclusions about how to solve
the problems.
<sg21_at_[hidden]> wrote:
>
> Cross-posting to SG15 and SG21.
>
> My goal with this email is to encourage collaboration between SG21 (Contracts) and SG15 (Tooling) on the contracts MVP well in advance of the design being presented and potentially approved by EWG.
The goal is fine, it's great. Some nitpicks follow.
> Some regular attendees of SG15 have expressed concerns that a contracts design (the MVP) might be accepted for C++26 without adequate tooling consideration thereby potentially leading to a situation like we have now with modules where we have a language feature with significant adoption challenges. I share some of these concerns.
I would hesitate to suggest or leave room for the impression that
modules were standardized without adequate tooling consideration.
Furthermore, some new language facilities just do have adoption
challenges, that's sometimes the nature of the beast. The
tooling-feedback
from e.g. build system developers hasn't thus far revealed a need to
do major design surgery to modules, as far as I have understood.
Keeping tooling people up to date is always a good idea, of course.
> Such use will be constrained for applications that have dependencies on packages provided by package managers. Package managers are unlikely to provide separate contract-disabled and contract-enabled builds, nor are system package managers likely to provide multiple builds (they don't provide separate assert-disabled and assert-enabled builds today for example).
Have you checked the validity of these predictions with system package managers?
> Use in production will require means to provide packages that, at run-time, can have any of the contract semantics (ignore, observe, enforce) enabled at load-time. This capability would require very low overhead means to enable such selection at load-time. Existing linker technologies like the GNU ifunc extension to ELF might pave the way to low overhead solutions.
..because this seems to take some of those predictions for granted,
and then seems to jump to conclusions about how to solve
the problems.
Received on 2023-11-09 20:10:11