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.
