assert semantic change proposal

[Daniel Gibson via Digitalmars-d]

Am 04.08.2014 03:02, schrieb Andrei Alexandrescu:
> On 8/3/14, 5:40 PM, Daniel Gibson wrote:
>> Ok, so you agree that there's a downside and code (that you consider
>> incorrect, but that most probably exists and works ok so far) will
>> *silently* break (as in: the compiler won't tell you about it).
>
> Yes, I agree there's a downside. I missed the part where you agreed
> there's an upside :o).

I see a small upside in the concept of "syntax that tells the compiler 
it can take something for granted for optimization and that causes an 
error in debug mode".
For me this kind of optimization is similar to GCC's __builtin_expect() 
to aid branch-prediction: probably useful to get even more performance, 
but I guess I wouldn't use it in everyday code.
However, I see no upside in redefining an existent keyword (that had a 
different meaning.. or at least behavior.. before and in most 
programming languages) to achieve this.

/Maybe/ an attribute for assert() would also be ok, so we don't need a 
new keyword:
   @optimize
   assert(x);
or @hint, @promise, @always, @for_real, whatever.

Cheers,
Daniel