On 04/09/16 01:39, Walter Bright wrote:
On 9/3/2016 6:14 AM, Jacob Carlborg wrote:
What kind of issue due you see with trying to print some form of
information
when an assertion fails?
Because it's useless to anyone but the compiler devs, and it adds cruft
to the compiler. And even worse than useless, it confuses the user into
thinking it is a meaningful message.
assert(0, "Compiler bug: symbol table should have been initialized by
this point");
This confuses the user less than the current situation, and at the same
time give people who are genuinely trying to have the compiler something
to work on to understand why the assert is there.
Speaking for my own, the RAID team in Weka started a rule saying not to
allow asserts with no strings in our code. Every assert should have a
message, preferably with parameters, giving some hint regarding what
went wrong and what the expected values should have been. It's a pain to
write them, but it more than pays off when they get actually triggered.
We just found out that having just the assert, even when the condition
makes it clear, even when there is a comment next to it explaining it,
is just too confusing. More often than you think, it also involves
cursing yourself for not having the value of one variable or another
(and, no, the cores are, more often than not, useless. I'm not sure why).
I understand you don't see the need, but I'd like you to consider the
possibility that having more people able to hack the front end is also
something that would help to give D a boost. If the cost of becoming a
compiler developer was lower, wouldn't things progress more rapidly?
Shachar
