Re: Library proposal - indexed_array

From: Hadriel Kaplan (hadrielk_at_[hidden])
Date: 2022-06-24 00:01:30

 On Thursday, June 23, 2022, 05:20:01 PM EDT, Richard Hodges via Boost <boost_at_[hidden]> wrote:
 
 > Yes, I'm looking for a real-world use case. The trivial hypothetical cases
> offered are building a static association between an enum value and some
> other value.
> This can be done with switch/case (for example), in about the same amount
> of typing, at compile time, in a function.

<snipped example switch-case code>
OK, now show me how to iterate over it. And how to get a view or slice of it (i.e., std::span or range). And how to get the number of elements. :)
I mean ultimately, it's a container. It's not _only_ useful for key'ed lookup retrieval.
You can change the value of whatever the container holds too, for example. Or maybe I'm misunderstanding your point? (could easily be the case)
Anyway, the main use-case or value of it, in my mind anyway, is actually the one when using Boost.Describe. Because when you're using Describe for an enum, you only need to do this for indexed_array:
indexed_array<string, MyEnum> data;
That's powerful, because you do not need to repeat any code, do not need to repeat any sizing/number of enums, etc. If you add new enumerators to your enum, you don't need to change this instantiation of indexed_array. It's all automatic, and you can't screw up.
The arbitrary intervals and non-contiguous use-cases I'm less convinced by. It's too easy to mess up.
And arguably it's not really a "indexed_array" at that point anyway - the underlying container might happen to be a std::array, but that's an implementation detail. From the user's perspective it's more like a "static_map" or some such. Except... it's not actually necessarily sorted, is it? All the examples show them sorted, but I'm not sure it really is if the user doesn't define it that way? (I'm trying _not_ to read the code - only the docs)
-hadriel