Re: enums that are really just sets of constants

[Jonathan Wakely <gtkmm kayari org>]

On 7 May 2017 at 15:10, Kjell Ahlstedt <kjellahlstedt gmail com> wrote:
> Den 2017-05-06 kl. 23:09, skrev Jonathan Wakely:
>
> On 6 May 2017 at 21:00, Murray Cumming <murrayc murrayc com> wrote:
>
> 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.
> _______________________________________________
>
> That might very well be useful. A minor drawback is that we would have both
> Gtk::Dialog::Response::OK (wanted) and
> Gtk::Dialog::Response::ResponseEnum::OK (unwanted). With an unnamed
> old-style enum there would be only Gtk::Dialog::Response::OK.
>
> namespace Gtk {
>   class Dialog : public ... {
>   public:
>     struct Response {
>       enum { OK };
>     };
>   };
> }
>
> An unnamed enum entails some restrictions, as discussed in
> https://bugzilla.gnome.org/show_bug.cgi?id=86864#c34, but that's probably
> not important for the very few enums in gtkmm and other mm-modules where we
> want implicit conversion to int.

Personally I find the downsides of unnamed enumerations types (can't
overload on the type, don't have a name to refer to the constants even
though they are allegedly related) are much worse than the fact there
are two ways to refer to the enumerations. I've never seen problems
arising from the fact that you could also write
Gtk::Dialog::Dialog::Dialog::Dialog::Response::OK (because of the
injected-class-name) so I don't see why the case you mentioned would
be a real problem.

If you're really worried about it:

namespace Gtk {
  class Dialog : public ... {
  public:
    struct Response {
      enum ResponseEnum { };
      static constexpr ResponseEnum OK = 0;
      static constexpr ResponseEnum ERR1 = 1;
      static constexpr ResponseEnum ERR2 = 2;
    };
  };
}

But I don't think that's an improvement.