assert semantic change proposal

[Walter Bright via Digitalmars-d]

On 8/5/2014 11:28 PM, Tofu Ninja wrote:
> Please stop responding in such a dismissive way, I think it is
> already pretty obvious that some are getting frustrated by these
> threads. Responding in a dismissive way makes it seem like you
> don't take the arguments seriously.

I responded to the equivalent design proposal several times already, with 
detailed answers. This one is shorter, but the essential aspects are there. I 
know those negative aspects came across because they are addressed with your 
counter:

 > How about something like
 > @expected assert(x > 2); or @assumed assert(x > 2);
 > It wouldn't introduce a new keyword, but still introduces the
expected/assumed semantics.

The riposte:

1. it's long with an unappealing hackish look
2. it follows in the C++ tradition of the best practice being the long ugly way, 
and the deprecated practice is the straightforward way (see arrays in C++)
3. users will be faced with two kinds of asserts, with a subtle difference that 
is hard to explain, hard to remember which is which, and will most likely use 
inappropriately
4. everyone who wants faster assert optimizations will have to rewrite their 
(possibly extensive) use of asserts that we'd told them was best practice. I 
know I'd be unhappy about having to do such to my D code.


 > You should keep in mind that you might have to make a compromise, regardless 
 > of your feelings on the subject.

This is not about my feelings, other than my desire to find the best design 
based on a number of tradeoffs.


I'll sum up with the old saw that any programming problem can be solved with 
another level of indirection. I submit a corollary that any language issue can 
be solved by adding another keyword or compiler flag. The (much) harder thing is 
to solve a problem with an elegant solution that does not involve new 
keywords/flags, and fits in naturally.