Help improve error message

[max haughton]

On Saturday, 6 May 2023 at 20:02:30 UTC, ryuukk_ wrote:
> First of all, a little quiz
>
>
> What should the error message be for the following code?
>
> ```D
> struct Something{}
>
> void main()
> {
>     Something test;
>     test.get();
> }
> ```
>
>
> Well.. it's not what you expect..
>
>
>
> ```
> onlineapp.d(6): Error: none of the overloads of template 
> `object.get` are callable using argument types `!()(Something)`
> /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3442):        Candidates are: `get(K, V)(inout(V[K]) aa, K key, lazy inout(V) defaultValue)`
> /dlang/dmd/linux/bin64/../../src/druntime/import/object.d(3449):                        `get(K, V)(inout(V[K])* aa, K key, lazy inout(V) defaultValue)`
> ```
>
> There is the actual error message, surprising right?
>
> ``Something`` is not an associative array, so why AA's 
> functions are in the candidate list?
>
> What ``Something`` has to do with ``object.get``??
>
>
> The correct and desirable error message should be:
>
> ```
> Error: no property `get` for `test` of type `Something`
> ```
>
> Not something confusing and misleading.. that's hard to debug
>
> Do you agree with that?
>
> If you do and want to improve D, then join me and try to fix 
> that behavior!
>
>
> 2 possible solutions that i can think of:
>
> - functions in ``object.d`` should be cleaned, everything that 
> has to do with ``AA`` should only work with ``AA``, and 
> everything that is generic, should be renamed so it doesn't 
> produce conflicts
>
> - DMD should be smarter and the logic for resolving the 
> function should reject these functions, so it can produce the 
> proper error message

This wouldn't be that hard to do but then you have a tradeoff 
between making this cleaner and making other contexts more 
confusing.

On the compiler side it would be interesting to make it output 
some kind of prose based on some kind of type pattern matching / 
unification e.g. rather than saying "Cannot call X with Y", we'd 
have a much more contextual error message that uses the 
information in the template signature (e.g. for `(K, 
V)(inout(V[K])` to be matched, it must satisfy the pattern, so 
must be an AA of type V[K]).

There's a dlang/projects entry for error messages, this would 
make a good thing to be done in that project.

As for the runtime, I'm not a big fan of these free functions 
either.