On Monday, September 10, 2018 1:44:22 PM MDT H. S. Teoh via Digitalmars-d wrote: > On Sun, Sep 09, 2018 at 12:27:52AM -0600, Jonathan M Davis via > Digitalmars-d wrote: [...] > > > IIRC, Weka has different types of assertions to differentiate between > > these two approaches - one for the cases which absolutely must not > > happen in production, and one that's purely for catching problems > > during developement. And really, I think that that's probably the > > right approach. > > [...] > > On Sun, Sep 09, 2018 at 09:20:11PM +0000, John Carter via Digitalmars-d > wrote: [...] > > > > > Let's face it, the term "assert" has been poisoned by decades of > > > > ambiguity. > > [...] > > > I beg humanity to give up on that word "assert" and come up with > > others words and define explicit the intent and meaning and > > implications. > > > > So much pain will be avoided. > > Indeed. D already distinguishes between assert (for catching > programming errors) and enforce (for catching runtime conditions like > bad user input). It's high time we distinguished between the various > flavors of assert, preferably with new words to avoid the baggage that > has accumulated around 'assert'. > > I propose: > > - 'assume': aborts on false condition in debug builds, not checked in > release builds, used as optimizer hint; > > - 'insist': aborts on false condition in debug builds, aborts on false > condition in release builds, used as optimizer hint; > > - 'uphold': aborts on false condition in debug builds, aborts on false > condition in release builds, NOT used as optimizer hint; > > - 'allege': logs error and aborts on false condition in debug builds, > logs error and continues on false condition in release builds, NOT > used as optimizer hint;
Honestly, that seems like total overkill, and I think that you would have a _very_ hard sell to get much of anyone to try to use four variants of assert, regardless of what they were. Also, why on earth would you suggest _not_ using it as optimizer hint in the case when it _aborts_ if it's false in both debug and release? At that point, it's guaranteed to be true if the code gets passed that point. There's a halfway decent chance that the compiler would end up using that information for optimizations even without it understanding anything special about the keyword, simply because it could guarantee that the condition was true for the code that followed just by seeing that the code aborted if it was false. If we were really going to do something to change the situation with assertions, I'd probably simply argue for adding a function to std.exception called something like require which was like enforce except that instead of throwing an exception on failure, it hit assert(0). The compiler should then be able to safely optimize based on that, and it would provide a standard way to require that a condition be true regardless of -release. At that point, there should be no need to optimize based on assertions, and they can be left as they have been (and as most people expect them to be) as a simple tool for catching problems during developement. If someone then wants to be paranoid and leave the assertions in by not compiling with -release, but that's their choice. Either way, I think that trying to do away with assertions based on the idea that there isn't always agreement on how they should be used is overkill, and I think that switching to having something like four different versions of assertions with new names is definitely overkill. IMHO, the biggest problem here is simply that optimizing based on assertions is dangerous if assertions aren't always left in, and since assertions are normally explained and used as a tool for catching bugs in development, most people use them with the idea that they're going to be removed in production with -release. So, they're not going to be left in production, and optimizing based on them is just going to be dangerous. That's what needs to be prevented here. We don't need a bunch of different types of assertions to solve that problem. We simply need to _not_ optimize based on assertions, and it would be a bonus to provide a standard way for people to put checks in their code that stay with -release, but such a function could trivially be written right now by anyone who wants it. We don't actually need to do anything special with the compiler, and we certainly shouldn't need to add separate helper functions to druntime or Phobos for every stray scenario of leaving checks in or not that we think someone might want. - Jonathan M Davis
