On Saturday, 3 September 2016 at 22:48:27 UTC, Walter Bright
wrote:
On 9/3/2016 6:20 AM, Adam D. Ruppe wrote:
On Saturday, 3 September 2016 at 12:12:34 UTC, Walter Bright
wrote:
Except that asserts are checking for compiler bugs, not
diagnostics on user code.
Except that in the real world, it is an irrelevant distinction
because you have
stuff to do and can't afford to wait on the compiler team to
actually fix the bug.
If nothing else, you'd like to know where it is so you can
hack around the bug
by changing your implementation.
Users are not equipped to do that, and we shouldn't raise false
expectations that they can. Developers who are equipped to that
are able and willing to build the compiler from source with
debugging turned on.
Really, what possible use is there to an end user for an assert
that unhelpfully printed out a message that the register
allocator failed? There's nothing "user friendly" about a such
a message.
I understand if you want to say producing better error
messages in the compiler
is a pain and you have other priorities, but surely you accept
that they are
valuable for this reason if nothing else.
No, I do not accept that, and I've had no trouble working
around asserts I've gotten from other vendors' compilers,
despite there being no message other than the compiler failed.
Most of the time it's the last change made that triggered it.
Back up one change and do something different.
In my experience getting a clue as to what is was the compiler
didn't like is very useful. Often the only way I can find a
workaround is by locating the assert in the compiler source and
working out what it might possibly be to do with, then making
informed guesses about what semi-equivalent code I can write that
will avoid the bug.
If the assert just had a little more info, it might save me a
fair amount of time.
