enum save/load split about cereal

[DrAWolf]

The use case is just serializing enums as strings. A common practice, I think. I do it every day.
You should definitely support that.

[AzothAmmo]

You are going to get errors because we made enum serialization a built in type supported by cereal, found in types/common.hpp, which is included by every archive. What is your use case where you want a custom serialization function for an enum? The only way to remove this issue would be for us to require people to include a header file (e.g. types/enum.hpp) whenever they serialize an enum.

If there is a clean way to get more information into static_assert messages, we'll look into it.

[AzothAmmo]

Just re-visted this and found a simple solution already in cereal. The reason you ran into this issue was that both our generic serialize function for enums (which is currently always pulled in) and your load/save pair were being seen as valid by the compiler, which cereal doesn't like. The way around this is to tell cereal to explicitly use a specific type of serialization function:

namespace cereal
{
  template <class Archive> struct specialize<Archive, MyEnum, cereal::specialization::non_member_load_save> {};
}

see access.hpp for more information on this.

I have a version where enum.hpp is its own header and I'm debating on whether to break it out or not, since with the above essentially one liner you can disambiguate for any type you want.

[AzothAmmo]

Also I'm going to add two macros: CEREAL_SPECIALIZE_FOR_ALL_ARCHIVES and CEREAL_SPECIALIZE_FOR_ARCHIVE that do what I typed out above but in a slightly less verbose looking fashion.

[Devacor]

Minor typo in the comment: Convenienct

Just pointing this out while it's fresh.