Help improve error message

[Steven Schveighoffer]

On 5/8/23 6:12 PM, Petar Kirov [ZombineDev] wrote:
> 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.]

Yeah, not touching that ;) To be frank, I've used swift's different 
integer types, and it sucks compared to D.

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

What is needed is to have the compiler try a different hook when this is 
expected. This is actually exactly what the compiler does for AAs -- a 
different runtime call is used when the result of the opIndex is 
expected to be filled in if absent.

I would not use `require`, but rather, another opIndex flavor. This 
shouldn't be tuned specifically to AA, we should do it right for all 
custom aggregates.


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

No, if we fix it, we should fix it once and for all. I don't think 
making AA into a library type is the only goal. The more D can allow 
people to write library types that mimic the builtins, the better off we 
will be.

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

Thanks! I think it's all pretty straightforward stuff -- implementing 
all the various AA things (like `require`, etc.), and being able to 
print the thing properly.

-Steve