kossebau added a comment.
Isn't the recommendation to rather avoid using things like QPair, and instead used properly defined structs? And ideally non-nested ones, to help with cases of forward declarations? Even QPair's API dox says so: "The advent of C++11 automatic variable type deduction (auto) shifts the emphasis from the type name to the name of functions and members. Thus, QPair, like std::pair and std::tuple, is mostly useful in generic (template) code, where defining a dedicated type is not possible." Code which uses ".first" and ".second" is harder to understand. And any users of the new API who want to pass in named colors but who cannot make use of auto-derived type name or init-list constructors, so have to explicitly write the name would also prefer some named type over QPair<QString, QColor>. So please reconsider using some non-nested struct, perhaps named e.g. "KNamedColor". The alias "ColorList" might be also confusing, as it misses to point out this is a list of named colors, not just a list of colors (one might naively think of QList<QColor>). "NamedColorList" would be less ambiguous. And as long as we are Qt5 at least., QVector would also be favourable here over QList given the size of the list item type and given that insertions are not expected to be typically done on this type. REPOSITORY R236 KWidgetsAddons BRANCH named_color_support REVISION DETAIL https://phabricator.kde.org/D29502 To: araujoluis, tcanabrava, patrickelectric, hindenburg, ngraham, #vdg Cc: kossebau, cblack, broulik, cfeck, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
