On Fri, Aug 01, 2014 at 10:39:44AM -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 8/1/14, 9:25 AM, Timon Gehr wrote: > >Even then, such a semantics is non-standard and almost nobody else > >knew. > > This notion of "standard" has been occasionally mentioned in this > discussion. I agree that D's assert is different from traditional C > and C++ assert, and I also agree that might surprise some, but I think > the meaning of D's assert is well within the intent of the larger > notion. > > >Why break 'assert' now, now that it actually behaves as I and many > >others expect (even some of those who argued for the (apparently, > >even inofficially) new and opposite design)? > > I don't see any breakage of "assert", more like realizing more of its > latent potential. Clearly the documentation could be better, which is > something we should focus on.
And to help with said focus, here's where y'all may direct your energy: https://github.com/D-Programming-Language/dlang.org/pull/624 ;-) > I do agree there's stuff that some may find unexpected, such as: > > assert(x > 42); > if (x <= 42) { > // let me also handle this conservatively > ... > } else { > // all good, proceed > ... > } > > The D optimizer might actually deem the entire "then" path unreachable > in the future, and only compile in the "else" path. Some may find that > surprising. For my money I never write code like this, and I consider > it incorrect if I review it. You either assert something, or you check > it dynamically. Exactly. T -- Winners never quit, quitters never win. But those who never quit AND never win are idiots.