Help improve error message

[Steven Schveighoffer]

On 5/8/23 5:53 AM, Petar Kirov [ZombineDev] wrote:
> On Sunday, 7 May 2023 at 14:19:49 UTC, Steven Schveighoffer wrote:
>>
>> [..]
> 
> I completely agree about you in the general case. However, just like you 
> highlighted the interaction between `std.conv.to` and `core.time.to`, I 
> believe we do have something we can do to improve the status quo in this 
> specific case, although not easily feasible in the current language - if 
> the compiler lowered `V[K]` types to a fully library defined type (say 
> `core.associative_array.Hash(Key, Value)`), then all the AA-related free 
> functions we currently have in `object.d` would become member functions 
> and then the compiler wouldn't consider them as overload candidates.

That possibly could improve the situation. UFCS "properties" for AAs are 
kinda sucky.

But that still leaves normal array properties, like `.dup`. I don't see 
us ever changing slices to templated structs.

> 
> Speaking of this, I now remembered that you created this project: 
> https://github.com/schveiguy/newaa
> 
> What language changes are necessary before we can replace the built-in 
> AAs with a completely library-based solution?

Two problems. One is straightforward, but requires some language 
updates: Having some mechanism to tell `opIndex` that the result should 
be inserted if it doesn't exist. Used in cases like:
```d
int[int][int] aa;

++aa[42][24]; // currently compiles
```

The second is not as straightforward. There are a few implicit casts 
that have no analog for structs. Without some way to say e.g. `Foo!(T)` 
can be casted implicitly to `Foo!(const(T))`, I don't know how we can 
figure that one.

Aside from that, there are a lot of things that can be done to newaa 
that will bring it closer to usable. I just haven't done them yet.

The biggest use case right now is building an AA at compile time, and 
using it at runtime.

-Steve