assert semantic change proposal

David Bregman via Digitalmars-d digitalmars-d at puremagic.com
Sun Aug 3 17:57:11 PDT 2014


On Monday, 4 August 2014 at 00:24:19 UTC, Andrei Alexandrescu 
wrote:
> On 8/3/14, 3:26 PM, David Bregman wrote:
>> On Sunday, 3 August 2014 at 22:15:52 UTC, Andrei Alexandrescu 
>> wrote:
>>> One related point that has been discussed only a little is the
>>> competitive aspect of it all. Generating fast code is of 
>>> paramount
>>> importance for D's survival and thriving in the market. 
>>> Competition in
>>> language design and implementation is acerbic and only 
>>> getting more
>>> cutthroat. In the foreseeable future efficiency will become 
>>> more
>>> important at scale seeing as data is growing and frequency 
>>> scaling has
>>> stalled.
>>
>> Would you care to address the questions about performance 
>> raised in the OP?
>
> I thought I just did.

You made some generic statements about performance being good. 
This is obvious and undisputed. You did not answer any concerns 
raised in the OP. I am left to wonder if you even read it.

>
>>> Availing ourselves of a built-in "assert" that has a meaning 
>>> and
>>> informativeness unachievable to e.g. a C/C++ macro is a very 
>>> important
>>> and attractive competitive advantage compared to these and 
>>> other
>>> languages.
>>
>> Not really, you can redefine the C macro to behave exactly as 
>> proposed,
>> using compiler specific commands to invoke undefined behavior. 
>> Didn't
>> you say in the other thread that you tried exactly that?
>
> That might be possible, but one thing I was discussing with 
> Walter (reverse flow analysis) may be more difficult with the 
> traditional definition of assert. Also I'm not sure whether the 
> C and C++ standards require assert to do nothing in NDEBUG 
> builds.
>
>>> Walter has always meant assert the way he discusses it today. 
>>> Has he
>>> (and subsequently he and I) been imprecise in documenting it? 
>>> Of
>>> course, but that just means it's Tuesday.
>>>
>>> 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.
>>
>> Please comment on the concerns raised by the OP.
>
> Probably not - there's little motivation to do so. The original 
> post is little else than a self-important rehash of a matter in 
> which everybody has stated their opinion, several times, in an 
> exchange that has long ran its course. Having everyone paste 
> their thoughts once again seems counterproductive.

Wow. Don't pretend like the questions are all "asked and 
answered". The concerns are legitimate, but the responses so far 
have been mostly arrogant handwaving. The fact that you believe 
you answered the performance concerns by merely stating 
"performance is important to make D competitive" is case in point.

There has been no evidence presented that there are any 
nontrivial performance gains to be had by reusing information 
from asserts.

There has been no case made that the performance gains (if they 
exist) justify code breakage and other issues.

There has been no effort to determine if there are alternate ways 
to achieve the goals which satisfy all groups.

I could go on, and on, but I refer you back to the OP. I really 
believe this whole thing could be handled much better, it doesn't 
have to be a zero sum game between the two sides of this issue. 
That's why I bothered to write the post, to try to achieve that.


More information about the Digitalmars-d mailing list