> On 14. Aug 2018, at 12:30, Tor Arne Vestbø <tor.arne.ves...@qt.io> wrote: > >> >> On 14 Aug 2018, at 12:13, Alex Blasche <alexander.blas...@qt.io> wrote: >> >> >> >>> -----Original Message----- >>> From: Tor Arne Vestbø >>> That circular logic 😊 Or at least arguing that we should maintain the >>> policy not >>> because it makes sense, but just because we’ve done so in the past. >>> >>> You are not questioning _why_ we have done so in the past (for decades as >>> you >>> say), which should be the input to whether or not we want to maintain the >>> policy >>> as is, or update it to match the current landscape of Qt and C++. >>> >>> The mere fact that we’ve had a policy does not have any value. >> >> Well, so far you only questioned the scoped enum case and making an argument >> for the scoped enum case based on so far accepted rules for unscoped ones >> is valid. > > So let’s explicitly make this a discussion about the whole policy then, since > it seems that wasn’t obvious 😊 > >> >> >>>> Therefore QQuickEventPoint::State::Pressed is no more verbose than >>> QQuickEventPoint::PressedState. >>> >>> Again, the policy does not mandate that in it’s current form in my reading >>> of it, >>> and even if it did, that would be a bad policy and we should fix it, not >>> just blindly >>> accept it as set in stone, because we’ve followed it "for decades". >> >> To quote the policy: >> >> "By comparison the following example illustrates the dangers of missing type >> safety and giving general names to conventional enum values:" >> ... >> " One guideline for naming enum types is to repeat at least one element of >> the enum type name in each of the enum values" >> >> I think the policy is explicit. > > The policy uses a global enum as an example. Obviously we need some sort of > scoping there, either in the enum value names, or by using scoped enums. We > agree there, and can leave that part of the discussion as solved. > > The discussion here is about what to do when the enum lives inside a class, > which would already solve the naming clash issue in most cases. > >> Whether you think it is bad is a different kind of thing. Please don't mix >> that. > > That’s kind of the point of bringing up a policy on the mailing list, to > argue that it’s bad, and we should change it… > >> Personally, I think this naming rule has served us well and although it is >> not consistently applied the majority of enums does follow them. >> >>>> In summary, there is very little verbosity added even by existing rules. >>>> Mind >>> you, Qt has always favoured readability and accepted verbosity as a >>> consequence in times of code completion. >>> >>> Code completion (for those that use it), only helps with writing code, and >>> as we >>> all know, most time is spent reading code 😊 >>> >>>> There is one more very important aspect. Scoped enums can have dedicated >>> types and are type safe. This could have easily caught issues like (which >>> coincidently was pointed out to me this morning): >>>> >>>> https://codereview.qt-project.org/#/c/236736/ >>>> >>>> And I believe that is a very good reason to still prefer scoped enums. >>> >>> How frequent is this class of bugs? >> >> Frequent enough for it being the primary driver behind the introduction of >> scoped enums?!? > > Do you have a source for this,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf states the problems that were the driver for creating strongly typed enums: 1. Implicit conversion to integer 2. Inability to specify underlying type 3. Scoping > that specifically mentions the enum inside a class use case a primary driver? Why would the implicit conversion problem be any different for enums inside a class? > > You conveniently left out this part of my reply: > >>> Clang warns about this with -Wenum-compare for both unstopped and scoped >>> enums, we could easily make that and error and have the best of both. > > > Cheers, > Tor Arne > >> >> -- >> Alex >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
