Hi all, https://www.sqlite.org/src/wiki?name=Bug+Reports said to send bug reports here; this is a documentation bug report for https://www.sqlite.org/assert.html#philosophy_of_assert_.
That page's section 1.1 Philosophy of Assert describes the SQLite project's philosophy about three different kinds of assertions - assert, ALWAYS, and NEVER - which I found very helpful and principled and would consider pointing other developers at when the topic arises. But then it inexplicably shifts into a critique of the Go language. The entire section reads: The Go programming language <https://golang.org/> omits assert(). The Go developers recognize this is contentious <https://golang.org/doc/faq#assertions>. Disallowing assert() is essentially telling developers that they are not allowed to do run-time verification of invariants. It is as if the developers of Go do not want coders to prove the software is correct. The SQLite developers believe that the lack of assert() disqualifies Go as a language for serious development work. I am the tech lead for the Go programming language and a big fan of SQLite. I often use SQLite as an example of well-written, reliable software (for example, in research.swtch.com/deps), and the Go SQLite3 binding was one of the earliest packages I wrote and published after the initial Go open source release. I don't understand the rationale for bringing up Go at all on this page. SQLite is not written in Go, and, as far as I know, you are not seriously considering rewriting it in Go. It seems especially odd to bring up Go apparently only to criticize it, even if the criticism were accurate. I also believe the criticism here is inaccurate. The linked text goes to the Go FAQ, which says: Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue to operate instead of crashing after a non-fatal error. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code. We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach. This text criticizing assert is trying to make the same point as the SQLite page, although without the nice vocabulary you have developed. Specifically, the paragraph preceding the SQLite page's criticism of Go says: Other systems sometimes use assert(X) in a way that is similar to the use of ALWAYS(X) or NEVER(X) in SQLite. Developers will add an assert(X) as a tacit acknowledgement that they do not fully believe that X is always true <https://blog.regehr.org/archives/1576>. We believe that this use of assert(X) is wrong and violates the intent and purpose of having assert(X) available in C in the first place. An assert(X) should not be seen as a safety-net or top-rope used to guard against mistakes. Nor is assert(X) appropriate for defense-in-depth. An ALWAYS(X) or NEVER(X) macro, or something similar, should be used in those cases because ALWAYS(X) or NEVER(X) will be followed by code to actually deal with the problem when the programmers reasoning turns out to be wrong. Since the code that follows ALWAYS(X) or NEVER(X) is untested, it should be something very simple, like a "return" statement, that is easily verified by inspection. This is *exactly* why Go has no assert. We completely agree that using assert to mean ALWAYS/NEVER is wrong and bad engineering practice. We also recognize that, like it or not, to a very large fraction of developers, assert has become synonymous with ALWAYS/NEVER hopes and dreams about proper execution, and then its availability encourages users not to "actually deal with the problem". Leaving assert out forces developers to think more about what they really mean when they go looking for "assert". It is of course possible to write all three meanings as trivial functions. For the specific case of run-time verification of invariants, a name like "invariant" might at this point be much clearer than the now hopelessly-fuzzy "assert". Getting back to the main bug report: It seems completely out of place in a document about SQLite's own coding practices (unless SQLite used Go!). Then of course it's even more out of place when Go's reasons for leaving out assert are being mischaracterized and actually quite well aligned with SQLite's philosophy. At most, we disagree only about whether the name "assert" can be salvaged for its original meaning. Could you please remove the paragraph about Go from https://www.sqlite.org/assert.html#philosophy_of_assert_, or else update it to reflect our actual position? For example, you could write instead that: In fact, the [https://golang.org|Go programming language] [https://golang.org/doc/faq#assertions|omits assert()] precisely to avoid the very common misuse as meaning ALWAYS. But removing the paragraph entirely seems cleanest, since even an accurate statements seems mostly out of place. Thanks for your help with this, and thanks again for SQLite! Best, Russ _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
