On Wednesday, 10 May 2017 at 15:50:06 UTC, Adrian Matoga wrote:
In this simple case above, I actually prefer DMD's messages, as
there's simply less text for my eyes to read and brain to
parse, so I can quickly spot where the problem is.
Well, even here, I'd prefer a small tweak:
lll.d(6): Error: none of the overloads of 'foo' match
given: foo(int , double)
lll.d(1): lll.foo(int a, int a)
lll.d(2): lll.foo(int a, string s)
The alignment would make it easier to eyeball the matches and
options... though that fails on longer lines too.
Another option is using colors (or something) to highlight which
ones in the candidates matched and which didn't.
The difference is small in a short case like this... but even
here, I'd call it slightly better, and in a big case, it is much
better.
It's indeed painful, but I found UDAs to be useful in dealing
with it.
Oh, that's on the declaration side, but this error message is on
the call side.
Suppose I pass an input range to sort(). I prove it is an input
range with UDAs or static asserts or whatever, yet the call to
sort fails. Why?
It is because sort requires more than just an input range, but
just whate is difficult to determine from the error message. So a
legible error message tells you WHAT you need to test on the
declaration ("must be random access"), then the udas can handle
those error messages (so like "it is not a random access range
because opIndex is not implemented")
Of course, the sort() function could check `isSortable` instead
of everything it lists in its constraint... and I think I'd like
that, but still, a more readable error message would be a big win.
The llvm people are just annihilating us in the error messages
and that's a bigger day-to-day boost than it seems.
So yeah, we should do both: make the decls nicer with UDAs, but
also make the error messages nicer for all cases.
oh another class of error messages that suck: "@nogc function
cannot call non-@nogc function map". but map is inferred so why
did it fail? wrote this up in bugzilla:
https://issues.dlang.org/show_bug.cgi?id=17374
I think RangeError could be solved without much effort by
changing the compiler/runtime interface at _d_arraybounds*.
Assertions are probably harder.
yeah, I actually tried to implement it one time and failed though
- the compiler code is a bit more fragile than I thought. Still
shouldn't be too hard, if I had a few hours to spend on it I
could prolly do it.
