assert semantic change proposal

[Andrei Alexandrescu via Digitalmars-d]

On 8/3/14, 3:35 PM, Daniel Gibson wrote:
> Am 04.08.2014 00:15, schrieb Andrei Alexandrescu:
>>
>> That said, should we proceed carefully about realizing this advantage?
>> Of course; that's a given. But I think it's very important to fully
>> understand the advantages of gaining an edge over the competition.
>>
>
> Gaining an edge over the competition?

Yes, as I explained.

> "A new DMD release broke my code in a totally unexpected way and people
> tell me it's because I'm using assert() wrong.

This has been discussed several times, and I agree there's downside. All 
I want to do is raise awareness of the upside, which is solid but 
probably less obvious to some. There's no need to trot again in response 
the downside that has been mentioned many times already.

> I've been using it like this in C/C++/Java/Python and D since forever
> and *now*, after >10years, they changed D's meaning of assert() to
> somehow imply assume() and optimize my safety-checks away.. they pretend
> it was always planned like this but they never got around to tell anyone
> until recently.
> It took me a week to find this freaking bug!"
>
> Doesn't really sound like the kind of advantage over the competition
> that many people would appreciate.
>
> If some rant like this (from Reddit or whatever) is the first impression
> someone gets of D, he's unlikely to ever take a closer look, regardless
> of the many merits the language actually has.

 From what I remember there has been good reception (both on reddit and 
at work) of increased aggressiveness of compiler optimizations.

> (Yes, Johhannes Pfau actually brought a similar  argument somewhere in
> the depth of one of the other threads)
>
> D could still get this kind of edge over the competition by doing these
> kind of optimizations when another keyword (like assume()) is used -
> without breaking any code.

I don't think D will add assume().


Andrei