"I made a game using Rust"

[Adam D. Ruppe via Digitalmars-d]

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- at 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.