Add variable definition for enum types

[Dakror]

I got tired of having to register custom getter and setters for every enum type i have in my structs, so i made this small utility change using std::underlying_type

[mikke89]

Thanks, this looks useful to me!

[mikke89]

I like this approach. A getter would be nice too, so we could use it for retrieving property values. Currently we set all enums using int as the type on properties, not sure if this could cause any issues.

I hope the library-wide formatting I decided to do isn't causing you too much trouble here. At least now you should be able to enable "format on save" if you have clang-format enabled on your editor.

There is also a large file here I don't think you intended to add.

[Dakror]

oops yeah the compilation database..

[Dakror]

I actually dont know what the best way for a setter would be, i dont want to be too invasive in the variant type. do you have an idea for it?

[mikke89]

I think your solution there already is good. Maybe, to be more generic, cast it to a specific integer type (int64_t?) before storing. Otherwise, if we don't support a specific underlying type, I suspect it won't compile. static_assert the size to be sure it fits in the int64_t. I think this should be safe?

Did you mean the getter? I think the same principle, we would need an SFINAE for GetInto enums. Maybe it is a good idea to measure compile times before and after this change :)

[Dakror]

im kinda stuck, dont know what im doing wrong in my getter... ideas?

[Dakror]

I worked around it using reinterpret_cast, not sure if thats a good idea though.

[mikke89]

I'm worried about using the type converter, because every time we use a new enum, there will be new type converter function invoked for each one of the other types in GetInto. This will quickly explode. In release mode, hopefully the linker will deduplicate the massive amount of functions that will be instantiated, but I'm worried compile times and debug mode will suffer.

I drafted something, partly based on your solution, for what I am thinking here: 7f34305

Just a small FYI, is_enum_v is a C++17 feature, we will need to use the more verbose is_enum::value.

[Dakror]

True thats a good point. Thanks for sharing your solution, i kinda figured using a temporary value for the GetInto function would be a version that could work.

Think we can just use your version then

[mikke89]

Alright, sounds good. Do you want to integrate that solution into your other changes here?

[mikke89]

I wanted a few more changes and just went ahead and committed them, hope that's okay. If you are happy with this then I am ready to merge it.

[Dakror]

looks good to me

[mikke89]

Alright, thanks again for the PR.