Date: Thu, 9 Nov 2023 15:35:43 -0500
On 11/9/23 3:09 PM, Ville Voutilainen via SG15 wrote:
> 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?
I have not; these are my expectations and if I'm mistaken, I won't be
disappointed. Regardless, there is an SG15 concern; if multiple package
variants are available, how does that impact application deployment and
configuration?
>
>> 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.
Sure, assuming my predictions hold. My intent is not to prescribe or
assert any particular solution. Please take the example given as a
possible solution to explore. I look forward to reading the ideas others
have.
Tom.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
> 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?
I have not; these are my expectations and if I'm mistaken, I won't be
disappointed. Regardless, there is an SG15 concern; if multiple package
variants are available, how does that impact application deployment and
configuration?
>
>> 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.
Sure, assuming my predictions hold. My intent is not to prescribe or
assert any particular solution. Please take the example given as a
possible solution to explore. I look forward to reading the ideas others
have.
Tom.
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
Received on 2023-11-09 20:35:44