ComptimeStringMap improvements

[data-man]

Useful for HTML entities, tags, color names, etc.

[squeek502]

I'm presuming the usual 'what about unicode' might apply here.

[squeek502]

By the way, case insensitive ComptimeStringMaps could be done with the status quo implementation by adding all strings as lowercase or uppercase at comptime and then converting the strings you want to look up to lowercase/uppercase before calling get. That might also be more flexible considering case insensitivity can be weird with Unicode.

Out of curiosity, are there any existing functions that deal with case insensitivity outside of std.ascii?

[data-man]

@squeek502

to look up to lowercase/uppercase before calling get.

It's inefficient.

[squeek502]

True. Maybe ComptimeStringMap should be more like the HashMap implementation and take an eql function? That'd allow for the same flexibility but without the performance hit.

[data-man]

Good idea!
Or can be added:

pubfngetSuperFlexible(str: []constu8, eql: fn (a: var, b: var) bool) ?VpubfnhasSuperFlexible(str: []constu8, eql: fn (a: var, b: var) bool) bool

[data-man]

Added:
ascii.eql
getWithEqlFn
hasCaseInsensitive
getCaseInsensitive
getMinLen()
getMaxLen()
getItems() because there is no way to get items after creating a map

[data-man]

@squeek502

I'm presuming the usual 'what about unicode' might apply here.

Now you can compare keys any way you want. :)

[data-man]

@squeek502

I'm presuming the usual 'what about unicode' might apply here.

Hmm,

if (kv.key.len!=str.len)
returnnull;

Keys can have different lengths, but can be equal with your comparison function (normalization, casing, etc.).

[squeek502]

Yeah, this implementation is heavily reliant on lengths being a short-circuit for inequality. For more robust/complex equality checks, something like ComptimeHashMap is probably better. See also what I wrote in the PR for ComptimeStringMap:

• It seems likely that the increased performance of this implementation is not very generalizable and is mostly geared towards the specific case of keywords, since the performance comes mainly from the keys being different lengths, and from the lookup being able to rule out inputs based on length (which also assumes that the get function will be called often with things that can be ruled out, which also seems specific to use cases like keyword lookup).
  • This makes me think this might be better somewhat hidden away but still accessible so that people can use it for their own tokenization implementations. Maybe somewhere in std.zig?

[data-man]

Yeah, this implementation is heavily reliant on lengths being a short-circuit for inequality.

So I think getMinLen() and getMaxLen() will be useful.

[andrewrk]

This has been WIP since June (the freebsd test failures look legitimate), please re-open if you wish to continue working on this.