News for hackers. Stuff that matters.
Re:The Use of assert() in SQLite by rabidrat on Friday April 26, 2019 @11:01PM (#19763499)
And then you can just #define assert(...) to eliminate it...oh wait, Go doesn't have a macro-preprocessor.
Re:The Use of assert() in SQLite by pstuart on Friday April 26, 2019 @11:09PM (#19763531)
To play along....

Go does have build tags, so one could have 2 files for the assert function, each with opposite build tag logic. It does allow for an effective NOP (it would be a stub function and I believe the compiler would eliminate that).

Re:The Use of assert() in SQLite by helper on Saturday April 27, 2019 @12:00AM (#19763695)
I tested this and it does indeed eliminate that code.
Re:The Use of assert() in SQLite by deathanatos on Saturday April 27, 2019 @12:19AM (#19763756)
I'm wondering if it inlines it (and thus eliminates it).

But this would come with a performance penalty: it makes the function you assert() in no longer a leaf function (it calls assert()) and AFAIK, Go only inlines leaf functions. (So, any function in which you call assert() is no longer eligible for inlining.)

Re:The Use of assert() in SQLite by helper on Saturday April 27, 2019 @12:53AM (#19763862)
chrchang523 is correct. In my test the caller function can still get inlined.
Re:The Use of assert() in SQLite by chrchang523 on Saturday April 27, 2019 @12:28AM (#19763780)
deathanatos: Go 1.12 can inline non-leaf functions, and I’d be surprised if it still fails to do the right thing here.
Re:The Use of assert() in SQLite by int_19h on Monday April 29, 2019 @01:09AM (#19775976)
It would still evaluate the condition in both cases, unless it can guarantee that the condition is a pure function with no observable side effects.