On 4/29/19, Russ Cox <r...@golang.org> wrote: > I were designing a new language, > the question of adding all three - invariant(x), always(x), and never(x) - > as a collective replacement for assert(x) would be an interesting thing to > consider.
There are benefits to having invariant(x) as a built-in in the language. A smart compiler might be able to detect cases where the invariant is false at compile-time, and thus provide earlier detection of programming errors. At the very least, the compiler could check to ensure that the argument to invariant(x) has no side-effects, and thereby avoid a common bug in the use of assert(). And if invariant(x) is a built-in, then code to actually check the invariant() at run-time can be included or omitted in the generated machine code, depending on optimization settings, without having to play games with preprocessors and macros. To reiterate the point of the original article - the key benefit of invariant(x) is that it is an executable comment. If I'm reading code that contains a comment describing an invariant, then I may or may not believe the comment (probably not, actually) but if I am looking at tested and working code that contains an invariant(x) statement, I have much more confidence that the given invariant is true. This GREATLY enhances maintainability of complex systems, in my experience. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
