Hey, > On 31 Aug 2018, at 14:50, Jan-Arve Sæther <jan-arve.saet...@qt.io> wrote: > > For me it seems that enum classes can help us create a more structured API, > because they also gives more semantic information, e.g: > QQuickPointerDevice::PointerType::Finger > gives more information than > QQuickPointerDevice::Finger
Again, showing the enum like this leaves out context that is usually there in real code: if (ev->pointerType() == QQuickPointerDevice::Finger) At which point the “more semantic information”, becomes “redundant semantic information”: if (ev->pointerType() == QQuickPointerDevice::PointerType::Finger) > For example, when doing code completion if I type "QQuickPointerDevice::" it > will give me _all_ members of QQuickPointerDevice (which I always have found > a bit annoying), but with an enum class I can type > "QQuickPointerDevice::PointerType::" and I will get listed only the valid > values (finally). Code completion should be able to look at the type you are comparing with (as above), and list the relevant enum values first (or only). We do that for function arguments don’t we, when suggesting variables to pass e.g.? > With the extra semantic I can even assume that the associated property for > the value QQuickPointerDevice::PointerType::Finger is called pointerType > (which it is). (I admit this is not always the case, but maybe it should be a > goal). Do you often go from enum value to property name? (Related but orthogonal, I notice our docs do not point back from an enum to functions that reference it. Perhaps there should be some automatic resolving there based on properties e.g. so that one doesn’t have to do \sa manually?) > And having it up for discussion for each review whether an enum should be > class enums or not just sounds like were planning for lots of bike-shedding > ahead. Is it better to forcefully enforce a coding style that is contended, and that might hurt code readability and our APIs, just to not “have to think”? > Last, maybe enum classes will lead to more ugly static_cast inside Qt, but > that's a cheap price to pay if it gives our users a better API (my point is > that a few awkward internal static_cast should not influence how our public > API is). What if it gives our users a _worse_ API? How does that balance look? Should we pay for that too? My -5 øre 😊 Tor Arne _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
