IO error should be a warning

[mwpowellhtx]

I am using Boost.Optional, and, while I do want to "include it in an output", the library which I am doing so has another mechanism to do so.

Translation, for Optional purposes, the following assertion should be a warning, IMO, and not an error:

BOOST_STATIC_ASSERT_MSG(sizeof(CharType) == 0, "If you want to output boost::optional, include header <boost/optional/optional_io.hpp>");

Specifically, I am handling "stringification" of the Optional for Catch unit test purposes, for which I have a String Maker setup for what I am doing.

Unless, mind you, it really is an error-error and should be covered, in which case, I suppose, yes, reporting an error assertion is appropriate.

That being said, when I ensure that the String Maker is included, the compiler is smart enough to detect this and it does not assert.

At the very least I do not think that the "error" should be quite as strong; i.e. when there are clearly alternatives to filling the output gap.

[akrzemi1]

Could you illustrate the problem you are facing in more detail? Can you explain what you mean by "String Marker"?

[mwpowellhtx]

String Maker is a Catch-ism, so to speak. In this case, where convert(T const&) is convert(boost::optional<...> const&).

When the include is made to my string maker, the assertion ("correctly") goes away; use case covered, I suppose?

However, when the gap exists, unless it's truly show stopping, I think it should be a warning and not an error assertion.

[akrzemi1]

So, if I understand correctly, you do not have a problem with this static assertion.

I fail to imagine a use case where somebody would like to go with serializing an optional without having included the declarations for serialization functions.

[mwpowellhtx]

No, I think the assertion (error) should be a warning, notwithstanding above caveats. That said, I think the "strength" of the assertion could be softened up; i.e. I've illustrated the "recommended" solution is clearly not the only path forward. I also do not need to include the _io header, at least in this case, when a String Maker is provided. Anyway, FWIW.

[mwpowellhtx]

I think I see what may be going on there. String Maker is converting the Optional value to a std::string, which does have IO comprehension... My apologies for the confusion. To clarify, when I comment out the String Maker include, the Optional is standing there directly facing the Catch reporting mechanism, so the assertion happens.

[mwpowellhtx]

I'm satisfied this is probably a mis-read on my part.