Open jeremy-rifkin opened 6 months ago
Thank you for the patience! I definitely want assertions in cpplinks (I'm a big fan of assert-early-assert-often, as in https://llvm.org/docs/CodingStandards.html#assert-liberally) and I think the library is great, too, so a perfect fit.
What I've been thinking of is where to put these exactly (category-wise). I'm still not quite sure, so perhaps you can help me out, if you feel like (or it's going to be me (over-)thinking out loud otherwise).
Context: I think there's value in having good categorization, so as to avoid growing into one big "awesome list" (subjectively I consider this an anti-pattern: For practical, selfish purposes I also want to be able to use cpplinks myself to quickly find what I need).
This is the background that resulted in debugging.tracing
being separate from debugging
, testing.fuzzing
being separate from testing
, or compilers.correctness
being separate from compilers
.
In the same vein, I'm wondering whether asserts fit into debugging
directly (in a defensive_programming
section, which is also what I'm not sure about), elsewhere, or whether these deserve a distinct category.
Some thoughts and open questions:
debugging
and testing
--or, arguably, broader (WIP) design
design
or correctness
static_assert
be still a good fit in that category (as in: if you were looking for resources on static_assert
would you look under debugging
?)--or warrant another one (which)? correctness
(thinking of A. Turing (1949) "Checking a large routine")? contracts
? design.correctness
?assertions
may be a better name (whether as a category or a section) as whether defensive_programming
itself is a good choice depends on the accepted meaning, with some differences and sources putting these in contrast, https://en.wikipedia.org/wiki/Offensive_programming
defensive_programming
, then would defensive_programming
fit as a part of, say, design.defensive_programming
?
https://github.com/CppCon/CppCon2014/blob/master/Presentations/Defensive%20Programming%20Done%20Right/Defensive%20Programming%20Done%20Right%20-%20John%20Lakos%20-%20CppCon%202014.pdfcorrectness#assertions
may be perhaps a better fit as debugging
doesn't seem to (directly?) cover use cases such as these (from https://blog.regehr.org/archives/1091):
(On a side note, perhaps error_handling
would fit under correctness.error_handling
?; One thing I'm sure of is that I agree with https://blog.regehr.org/archives/1091 that asserts themselves do not belong in the error_handling
category. This does however make me hesitate to just create top-level assertions.md
if there's a broader category that would be a better fit. FWIW, in retrospect I think using top-level atomics.lockfree.memory_model.md
directly was a mistake--and concurrency
would have been a better choice.)
Let me know if you have any thoughts on these; thanks!
Hi Matt! Thank you for the context on the organization of the project. I'm happy to opine, however, you have definitely given this much more thought than I have. (And TIL about offensive programming)
The main concepts to me seem to be defensive programming / "assert early assert often" philosophy, design by contract, and error handling. To me these fit very comfortably under a correctness
(or design.correctness
) category.
static_assert
is tricky to place. To me many uses of static_assert
seem comparable to contracts, such as static asserting that a struct is a certain size or satisfies certain concepts, and I wonder if it would fit under a design by contract sub-category.
This PR adds links to libassert (shameless plug, I'm the author), and Bloomberg bsls_assert as resources for defensive programming