Use a enum class for QoS type

[guilhermeferreira]

Convert to integer only in the interface with Paho MQTT C. This ensures that QoS will be used consciously. And the user will not provide an arbitrary integer instead of a QoS value.

      +-----------------+
      |                 |
      |  Paho MQTT C++  | <-- Use only QoS enumeration
      |                 |
      +-----------------+ <-- Conversion between QoS enum and int
      |                 |
      |   Paho MQTT C   | <-- Deal with interger QoS
      |                 |
      +-----------------+

The mqtt::QoS enumerators have sizeof(int) because an array of QoS might be cast to an array of integers. Thus, each element must have the same size.

[fpagliughi]

I'm not convinced of this one. By close compatibility with the C library, and a convention across most of the Paho libraries, the QOS is just typed as an int. It is discussed by its integer values (0, 1, 2) in documentation and lists, and might be more confusing as an enumeration than just leaving it as an int.

[guilhermeferreira]

My initial idea was to improve type safety. But thinking again, a QoS enumerator name might be more confusing than a simple number.

[guilhermeferreira]

If you are concerned about readability, what do you think about using the numbers as enumerators? Something like this:

enum class QoS: int
{
  QoS0 = 0,	// Fire and Forget
  QoS1 = 1,	// Acknowledged delivery
  QoS2 = 2,	// Assured delivery
};

My idea here is to let the compiler warn if someone is using an arbitrary integer variable, or a constant, instead of a QoS value. The validation function (validate_qos()) works at run-time. On the other hand, this enum class method provides compile-time verification. For example:

mqtt::QoS qos = mqtt::QoS::QoS1;
// ...
qos = some_integer; // Error: compiler can spot
// ...
mqtt::message msg("payload", qos, true);
mqtt::will_options willopt("topic", "payload", qos, true);

[miketran78727]

Will this break existing applications? If yes, please do not do this.

[fpagliughi]

I think to leave the QoS as an int for v1.0. A major point of the initial release was compatibility with the other Paho libraries, so let's stick with their lead.
Looking into the future, a v2.0 release might break away from this stricter compatibility and do a few things that are a bit more C++ centric. I would assume that might also go with C++14/17 requirement, and might possibly be an optimized, stand-alone library.