On Fri, 3 May 2019 at 16:03, Dominique Devienne <ddevie...@gmail.com> wrote:
> On Mon, Apr 29, 2019 at 9:49 PM Russ Cox <r...@golang.org> wrote: > > > On Mon, Apr 29, 2019 at 3:28 PM Richard Hipp <d...@sqlite.org> wrote: > > For what it's worth, it was not clear to me until just now that the > article > > existed to push back on a general "asserts considered harmful" notion. I > > was reading it as primarily documenting SQLite coding conventions. The > > reference to Go makes more sense to me now. > > > > Very interesting discussion between two of my very favorite programmers. > Thanks. > Seconded! > But I also regret the lack of invariant/always/never (I dare not say > assert...) in Go. I wish Robert/Rob/Ken/Russ instead of shunning > "assertions" would > promote "proper use" of invariant/always/never by making them a built-in > part of the language, and have the compiler perform the kind of static > analysis > Richard mentions in this thread. My $0.02. --DD > This is getting off-topic, but the immediate question arising from this proposal is what would you _do_ in response to a violation? For those unfamiliar with go, the language doesn't feature exceptions. The only stack-unwinding mechanism is to call panic(), which will terminate the entire process (unless captured by a call to recover() before unwinding the entire stack). Go is also a very modular language, designed to be very easy to drop other people's code/libraries into your project. But there's a very clear convention set out surrounding the use of panic() - it should never form part of a module's public API. It's not an error reporting mechanism and callers should never be expected to invoke recover() just to use your module. I can't see another way to implement invariant/always/never other than creating some "blessed" form of panic(), and if you do that then the cross-module convention shifts from a very clear "DO NOT" to a more subtle "UNLESS THINGS HAVE GONE REALLY SIDEWAYS." Now there's a judgement call involved in whether it's acceptable for a given API call to bring the whole process down when provided nonsense state, and since judgement varies between individuals the effect that has on the entire go ecosystem could be huge. And I guess this is the core of the disagreement - when used "correctly" assertions are informative and helpful but there's no way to enforce "correct" usage. Admittedly you could say this about a lot of programming constructs but I don't think we can do away with arrays just yet! But it also highlights one of the great things about go, which is that you don't have to agree with all its design decisions to reap their benefits. There's real advantages to sticking to your guns when it comes to conceptual integrity, even if it doesn't suit absolutely everybody. It's why we like the "lite" in sqlite, no? -Rowan (aka sqweek -- hi Russ ^_^) _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
