assume, assert, enforce, @safe

[H. S. Teoh via Digitalmars-d]

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.