`Expects` and `Ensures` should be `GSL_EXPECTS` and `GSL_ENSURES`

[sean-parent]

GSL should obey the core guidelines. Expects and Ensures should be GSL_EXPECTS and GSL_ENSURES. As the person who has suffered for 30 years for defining widely used macros check and require I can attest to just how bad an idea those names are. (https://opensource.apple.com/source/xnu/xnu-7195.141.2/EXTERNAL_HEADERS/AssertMacros.h.auto.html)

[dmitrykobets-msft]

Hi @sean-parent,

I looked over the related discussions:

• GSL Expect() and Ensure() and the CppCoreGuidelines naming convention isocpp/CppCoreGuidelines#993
• What a bout adding : Avoid macro name collision by prefixing all the macros with a prefix isocpp/CppCoreGuidelines#227
• Avoid the use of macros as Expected #35
• GSL.assert macros should be methods #75
• GSL violates CppCoreGuidelines both ES.32 and ES.33: #801

From what I've gathered, it seems like there was hope that contracts would be introduced soon enough, and that for the time being these checks were implemented as macros because of some technical caveats. And because the macros were considered an "implementation detail", their names were chosen purposefully to conform to I.6 and I.8.

However, these discussions are quite old and things have changed since then, so I'll re-surface this topic in the next GSL maintainers' sync.

Thanks,
Dmitry

[robert-andrzejuk]

@dmitrykobets-msft Did you have "contracts" in mind instead of "concepts" in the sentence: "...like there was hope that concepts would be introduced soon enough..."?

[dmitrykobets-msft]

@robert-andrzejuk oops, yes I did thanks for the catch -- updated

[dmitrykobets-msft]

Hi @sean-parent,
It looks like because the macro behavior is documented explicitly in https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#gslassert-assertions, the discussion will have to start with the Core Guidelines. But there's currently other work being done with regards to Expects/Ensures #962 that will also need to touch base with the guidelines, so we'll try and include this discussion as part of that related work.
Thanks,
Dmitry