Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-104110

Support easy, yet precise, documenting of relational operators

    XMLWordPrintable

Details

    • 21
    • Foundation Sprint 72, Foundation Sprint 73, Foundation Sprint 74, Foundation Sprint 75, Foundation Sprint 76, Foundation Sprint 77, Foundation Sprint 78, Foundations Sprint 79, Foundations Sprint 80, Foundation Sprint 81, Foundation Sprint 82, Foundation Sprint 83, Foundation Sprint 84, Foundation Sprint 85, Foundation Sprint 86, Foundation Sprint 87, Foundation Sprint 88, Foundation Sprint 89, Foundation Sprint 90, Foundation Sprint 91, Foundation Sprint 92, Foundation Sprint 93, Foundations Sprint 94, Foundations Sprint 95, Foundations Sprint 96
    • 3d3970d75 (dev), 575e9c7fa (dev), 24627d9bc (dev)

    Description

      C++20 brings a new 3-way relational operator and three classes of comparison result: strong, partial, and weak ordering (cf. epic). We need an easy way to document

      1. the class of comparison result that applies to the type: strong, partial, weak
      2. which other types this type can be compared with

      qdoc should then do the rest.

      Example: QByteArray

      \class QByteArray
      \stronglyordered
      \comparesto QByteArrayView, const char*, const char8_t*, ...
      

      This is all a class author should need to do. Output should be something like:

      class QByteArray
      
      This class is _strongly comparable_ (link to description).
      
      It can also be compared to <list or table>
      
      <add function documentation for each op in {==, !=, <, >, <=, >=, <=>}, complain if one is missing>
      

      This is for less-than-comparable types. We'll need something similar for equality-comparable-non-less-than-comparable types, such as QRect:

      \class QRect
      \stronglyequalitycomparable 
      \comparesto QRectF
      
      \class QRectF
      \partiallyequalitycomparable
      \comparesto QRect
      

      Scope for this ticket is to finalize the concept and generate buy-in from the Documentation team and the qdoc maintainers for it.

      Acceptance criteria:

      • common understanding of the solution between Documentation team, qdoc team and C++ developers, incl. buy-in
      • follow-up tasks defined for each of Documentation, qdoc, and C++ teams

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

              treinio Topi Reiniƶ
              mmutz Marc Mutz
              Vladimir Minenko Vladimir Minenko
              Alex Blasche Alex Blasche
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes