[fpc-devel] Who maintains TDictionary? // Re: RFC: Improvements for TDictionary and other hash containers

[Michael Van Canneyt]

On Sun, 13 Apr 2025, Martin Frb via fpc-devel wrote:

> On 13/04/2025 19:49, Michael Van Canneyt wrote:
>>
>>
>> On Sun, 13 Apr 2025, Martin Frb via fpc-devel wrote:
>>
>>> Just want to know if there is any interest?   Or if I just gonna do 
>>> my own copy (somewhere in LazUtils)
>>
>> The 1-4 are interesting so MR is welcome,
>
> ok, I will work on that.

We look forward to the MR...

>
>
>> the 5 I don't understand what you want to
>> achieve, I would assume a custom comparer is simply the answer ?
>
> The custom comparer (and hasher) I already have. But its not enough.
>
> The concrete use case is the SynEdit Highlighter.

If I had bet on the use case, I would have won my bet ;-)

> Instead I like to do
>   type
>     TMyEmpty = record end; // empty
>     specialize TDictionary <TRange, TMyEmpty>
>
> Then only the key is stored.
>
> But then I need a way to retrieve the existing key, for a new key that I 
> have.

But why don't you simply use a TList<TRange> with your custom comparer ?
You can then use List.BinarySearch() and retrieve the existing TRange at once?

Your solution seems quite hackish to me. 
So if you really need it in TDictionary, make it protected as you indicated...

Michael.