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
