genericize `DataIdentity` for container types

[ab9rf]

this partial rework of the data identity system provides genericized support for container types using concepts, and in general cleans up and modernizes this code

this doesn't cover several the std::vector specializations, still figuring out the best way to do that so this can be considered WIP but this code works on Windows and so i am putting up a PR mainly to run CI tests and see if gcc likes this or not

the process of going through this code has identified a number of other possible refinements that should probably be done which i'll come back to after i've had some rest

[Bumber64]

Seems to work for me. I can pass a vector into Lua and modify it.

[Bumber64]

Regarding std::unordered_map, the keys (i.e., first) aren't accessible by Lua. Running pairs on it gives 0-n for keys and just the value of second for values (i.e., not {first, second}.)

Any attempt to insert into std:unordered_map<int, std::string> via Lua got me the error Temporaries of type string not supported. Same for std::unordered_set<std::string> and ordered versions.

[ab9rf]

Regarding std::unordered_map, the keys (i.e., first) aren't accessible by Lua. Running pairs on it gives 0-n for keys and just the value of second for values (i.e., not {first, second}.)

Any attempt to insert into std:unordered_map<int, std::string> via Lua got me the error Temporaries of type string not supported. Same for std::unordered_set<std::string> and ordered versions.

The Lua interface to C++ associative containers is at best shoehorned and needs to be reconceptualized. This PR may not be the best place to do this.

[Bumber64]

The Lua interface to C++ associative containers is at best shoehorned and needs to be reconceptualized. This PR may not be the best place to do this.

Should I open an issue at this time? I don't need it for anything I'm working on. I just remembered it being mentioned on Discord as something to test. If nobody ever ends up needing it, then it'd be kind of pointless. (I guess Bay12 might use the type eventually?)

[ab9rf]

If nobody ever ends up needing it, then it'd be kind of pointless. (Bay12 might use the type eventually?)

Bay12 is already using std::maps in several places (notably in some of the interface-related stuff) and I seem to recall myk mentioning that having them fully available from lua would be useful in some places already.

Our current Lua interfaces only supports reading the "values" list as if it were a regular array, and does not support modifications at all. I personally believe that it would be good to move past these limitations.

[ab9rf]

Let me add here that this code is not really ready to go yet. I really want to extend this to encompass std::vector<T*> which right now is still being handled by the old stl_ptr_vector_identity, but this isn't just a matter of removing the latter specialization, changes also have to be made to the generic_container_identity for the special handling that vectors of pointers require.

I did test to see what happens if you just remove the specialization: the launcher sprouts hundreds of scrollbars, which is both hilarious and entirely unhelpful.

[lethosor]

Should I open an issue at this time? I don't need it for anything I'm working on. I just remembered it being mentioned on Discord as something to test.

Was that something I said? I didn't mean that unordered_map should have any particular functionality, just that this code should (a) compile and (b) not have any regressions when handling instances of unordered_map. The behavior you're pointing out is a known limitation that was present before this change. Not great, but not a regression.

[ab9rf]

does this deserve a changelog line (probably under API)?

lemme finish writing it first lol

[lethosor]

I'm not sure it does. It's really not a user-facing change. The only aspect that could affect some external devs is the ability to define std::arrays in df-structures, so I would probably put it under Structures, if anything.

[ab9rf]

the main "features" this PR offers are the ability to pass a wider range of types into Lua from C++, especially from plug-ins, future proofing the identity system to possibly support a broader range of container types (which we expect to be likely to arise as we continue to extend/revise structures), and general code quality (at least i would like to think so)

all of this is basically being driven by bay12's increasing use of C++20 paradigms that our identity system was never designed to work with. the existing system having was basically designed using C++03 + "boost but not really boost" which are at best dated by modern standards, but which worked very well with toady's C++98ish style of coding DF itself, and which doesn't necessarily play that well with C++20 which we are increasingly moving toward both because C++20 has some really nice paradigms (i am especially fond of std::range) but more because bay12 (with putnam now on board) is clearly moving rather quickly in that direction

i'm very much cognizant of the fact that we have, in recent revisions, added several types to structures that are currently being handled as opaque types within the Lua identity system but which really ought to have more meaningful Lua semantics. while this PR does not itself resolve this issue, i'd like to think that it's a step toward a more flexible identity management system that will hopefully enable us to do so. specific goals i have in mind here include making std::function objects directly callable from Lua (without explicit C++ glue code), allowing Lua code to manipulate the contents of C++ associative containers (including at the very least std::map, std::unordered_map, and std::set), and transparent support in Lua of types wrapped with std::optional or std::shared_pointer

anyway, i don't think any of this merits a changelog since it's 90% inside baseball and really only impacts the core team, at least initially. we didn't changelog #4406 as far as i know, and this is basically the same type of change as that was

[ab9rf]

i'm moving this to draft status because i am not convinced that it's worth pursing at this time