Re: enums that are really just sets of constants

[Jonathan Wakely <gtkmm kayari org>]

On 6 May 2017 at 21:00, Murray Cumming <murrayc murrayc com> wrote:
> On Sat, 2017-05-06 at 18:08 +0100, Daniel Boles wrote:
> > So it seems that the only option is to continue using C-style enums
> > within classes, e.g. class Dialog { enum ResponseType{} } as
> > present.. As someone already mentioned, I see no problem with this:
> > such an enum is not inherently bad in itself; it's only bad if chosen
> > in o s case where another solution (enum class, constexpr, etc.) is
> > an available and more appropriate option. As that does not apply, the
> > C-style enum should continue to serve this purpose well.
>
> The old style-enum won't let us change this, in gtkmm 3,
> Gtk::RESPONSE_OK
> into this, in gtkmm 4:
> Gtk::Dialog::Response::OK
> without also polluting the API with this
> Gtk::Dialog::OK
>
> Using an old-style enum would let us have this:
> Gtk::Dialog::RESPONSE_OK,
> (and Gtk::Dialog::Response::RESPONSE_OK)
> which is still an improvement, but not quite as nice.

Strictly speaking, an old-style enum *and* a scope would allow that.

namespace Gtk {
  struct Dialog {
    struct Response {
      enum ResponseEnum { OK };
    };
  };
}

That would give you the implicit conversions of old-style enums, but
still give scoped names. That might not be useful, I'm just saying
it's possible.