Problem (de-)serializing an enum with value 0 if the | operator is overloaded

[florian-n]

Hello,
I am unfortunately running into an issue with the newest version of the reflect-cpp lib.

Assume I have something like this:

enum class TestEnum : uint64_t
{
	None = 0,
	Hello = 1 << 0,
	World = 1 << 1,
	HelloWorld = Hello | World
};
struct SomeClass
{
	TestEnum e;
	TestEnum f;
	TestEnum g;
};

void Foo()
{
	SomeClass t{.e = TestEnum::None, .f = TestEnum::Hello, .g = TestEnum::HelloWorld};
	const auto jsonString = rfl::json::write(t);
	const auto t2 = rfl::json::read<SomeClass>(jsonString).value();
}

^Works fine. The object will be serialized to {"e":"None","f":"Hello","g":"HelloWorld"} and back as expected.

The issue arises once I overload the | operator:

static constexpr TestEnum operator|(TestEnum a, TestEnum b) noexcept { 
	return static_cast<TestEnum>(static_cast<uint64_t>(a) | static_cast<uint64_t>(b)); 
}

This changes the serialization to {"e":"","f":"Hello","g":"Hello|World"}. The "Hello|World" part is expected, as per your documentation.

The issue is that what was previously "None" was now serialized to the empty string "", eventually failing the de-serialization step with the error "Failed to parse field 'e': Invalid enum value: ''. Must be one of [None, Hello, World].".

I am unsure what the expected behavior should be. I can see all variants "None", "" and "0" make sense. Imo the bigger problem is the fact that the immediate de-serialization fails.

I would be very thankful for your help!
Best, Florian

[liuzicheng1987]

@florian-n thanks for reporting, I'll take a look

[liuzicheng1987]

@florian-n the problem is that you cannot assign 0 to a flag enum. As stated in the documentation, values for flag enums must be 1 or 2^N, but zero is not among the supported values.

The moment you assign operator|, your enum is recognised as a flag enum.

[florian-n]

Thank you for the quick response.

I understand that part. However, I'd argue that 0 is a legitimate value as in "I chose none of those flags". Hence, I can see all three options as reasonable:

• "None" -> "Workaround" if a 0-valued option is explicitly defined (probably the least logical bust most human readable)
• "" -> To get noting, you have to |-concatenate noting
• "0" -> Your documentation also mentions "If an enum cannot be matched, it will be written as an integer."

That being said, I think the bigger issue is that the de-serialization fails. No matter what option is the desirable one, I'd expect the de-serializer to understand the output of the serializer and reconstruct the original object.

[liuzicheng1987]

@florian-n, OK, this seems to be a bug in the enchantum library. I will take a look.

[florian-n]

Thanks, I appreciate it!

I'd suspect its this bit in enums.hpp:70, that essentially skips over the 0 value:

while (val != 0) {
  const auto bit = val & static_cast<T>(1);
  if (bit == 1) { ... }
  ++i;
  val >>= 1;
}

I ended up "hotfixing" it by explicitly checking for 0 like this:

if (static_cast<std::underlying_type_t<EnumT>>(_enum) == 0)
{
	const auto s = enchantum::to_string(_enum);
	ParentType::add_value(_w, s.empty() ? std::string("0") : std::string(s), _parent);
}

[liuzicheng1987]

@florian-n , this was indeed an unhandled edge case; this PR should fix it:

#644

Thanks for reporting!