Help improve error message

[Petar]

On Monday, 8 May 2023 at 16:08:32 UTC, Steven Schveighoffer wrote:
> [..]
>
> 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.

Hmm, that doesn't sound like the worst idea. From implementation 
point of view, we much be extra careful to avoid any sort of 
pessimization (e.g. template code bloat), since slices are used 
everywhere, but other than that, why not?

In some languages, even built-in integer types are 
"library-defined", see e.g.:

Swift:
* 
[`stdlib/public/core/IntegerTypes.swift.gyb`](https://github.com/apple/swift/blob/main/stdlib/public/core/IntegerTypes.swift.gyb)
Rust:
* 
[`library/core/src/ops/arith.rs`](https://github.com/rust-lang/rust/blob/a0111af531178e48375f14f838d7a2298524067c/library/core/src/ops/arith.rs#L94-L109)
* 
[`library/core/src/num/int_macros.rs`](https://github.com/rust-lang/rust/blob/a0111af531178e48375f14f838d7a2298524067c/library/core/src/num/int_macros.rs)
* 
[`library/core/src/num/mod.rs`](https://github.com/rust-lang/rust/blob/a0111af531178e48375f14f838d7a2298524067c/library/core/src/num/mod.rs#L245-L264)

Anyway, let's not get ahead of ourselves.

>> 
>> 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
> ```

Yeah, the so-called 
[autovivification](https://en.wikipedia.org/wiki/Autovivification). For a moment I was confused as to what's the problem with simply:
1. Having `opIndex` return by `ref`, so you can mutate the value 
in-place.
2. Having `opIndex` construct the value on first access, 
something along the lines of:
   `if (key !in impl) return impl.at(key).emplace!Value();`

But then I remembered that `aa[missingKey]` actually throws a 
`RangeError` and we wouldn't be able to replicate the behaviour 
if we did 2.

I wonder if the compiler simply could lower:

```d
int[int][int] aa;
++aa[42][24];
```

to:

```d
int[int][int] aa;
++aa.require(42).require(24);
```

Would that address this issue?

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

Thanks for reminding me, I think this was discussed many times in 
the past, IIRC it was most recently brought up by deadalnix in 
the sumtypes thread.

If we consider this issue unsolvable for the time being, a 
pragmatic way forward would be to consider the following:
The compiler already special cases `T[]` and `V[K]` types with 
regards to type qualifiers. Perhaps we can keep this code around 
and update it to work with the new AA implementation. That would 
mean that the implicit type qualifier conversion won't work if 
one directly imports the AA type: 
`core.associative_array.Hash!(K, V)`, however existing code that 
uses the `V[K]` syntax would continue working fine.

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

Nevertheless, I think you have very solid progress so far! 
Hopefully, it won't be too long before we incorporate it in some 
form in Druntime!