Re: enums that are really just sets of constants

[Kjell Ahlstedt <kjellahlstedt gmail com>]

Den 2017-05-23 kl. 10:44, skrev Daniel Boles:

This seems too simple to be an option, but I have to ask :) What about ResponseTypeClass or similar? It seems like the most specific thing (without getting ridiculous like ResponseTypeDummyScopingClass, heh)

Having said that, my reflex is still to prefer class ResponseType { enum EnumOrAnonymous {...} } - which I know was discussed:

https://bugzilla.gnome.org/show_bug.cgi?id=86864#c29

but I don't really see why it was rejected in favour of the current proposal involving the typedef.

Kjell said:

[The things I want are] perhaps possible to achieve if ResponseType is the name of the class,
but it won't be a minimal wrapper class.

Why not? Surely it can stlll be final/uninstantiable/etc? All that changes is the names of the class and its contained enum, and the fact that you would not need to generate a using declaration for the latter. Things like ResponseType::NONE are still possible and work anywhere that an int or enumerator would be expected.

I don't understand how you can have, for instance
  void f(ResponseType r);
if ResponseType is an uninstantiable class. If ResponseType is the name of a class, and you want to treat it as if it were the name an enum, wouldn't it require something like

  class ResponseType final
  {
  public:
    enum Enum
    {
      NONE = -1,
      REJECT = -2,
      ACCEPT = -3,
      ...
    };
    ResponseType() = default;
    ResponseType(Enum value) : m_value(value) {}
    operator int() { return m_value; }
  private:
    Enum m_value = Enum();
  };

Do I require too much of these enums? I try to make something that can be used like an enum class, except for one thing: It shall be implicitly convertible to int. I suspect that this gtkmm-list thread has become longer than necessary because our requirements have been very vague.

Kjell