I managed to mangle copy pasting to the mail, so probably better to read from the wiki page rather than read everything twice in a tricky order.
On 20.11.2019 21.20, Kari Oikarinen wrote: > Hi! > > Here are the notes for the C++17 related session held today at QtCS. I > tried my best to capture the discussion, but there might still be a lot > of errors. > > Notes are also in the wiki at > https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes > > # Language > > > ## if constexpr > > # Language > > > ## if constexpr > > Very useful for our containers. > > > ## Fold expressions > > Shortcut for handling parameter packs of vadiadic templates. No need > to write recursive template helpers. > > > ## Inline variable > > Volker: What is the impact of using inline variables to static data > initialization? How do we deal with `Q_GLOBAL_STATIC`? > > Inline variables are safer than static globals. Compiler and linker > guarantee that there will be just one definition. > > `Q_GLOBAL_STATIC` still provides lazy initialization. So inline > variables are not a full replacement. Any big globals that aren't > necessarily used should be gated by lazy initialization to avoid > constructing them unnecessarily. > > > ## Polymorphic lambdas > > What is it? It has auto as its parameter type. So the same lambda can > be used with multiple invocations with parameters of different types. > > Most common use is just for brevity. It gives you perfect forwarding > as well, if you use auto && as the type. > > But these are not API visible, just perhaps useful inside the > implementation. > > > ## Structured bindings > > QRect and QPoint might be possible candidates. But there will not be > many that this makes sense for. > > Some of these will already be aggregates and work automatically. But > perhaps they for example have user-defined constructors and so don't > fulfill the requirements of that. > > > ## Language attributes > > There are macros for many standard attributes, like nodiscard, > deprecated, fallthrough, likely and unlikely. > > When is the right point to remove this macros and use the attributes > directly? When all compilers support it. Although that causes pain > when backporting to older branches. > > That applies to all language features, though. Some backporting is > really hairy, like converting if constexpr solutions back to template > specializations. > > > ## Modules (C++20) > > Properly modularizing Qt is going to be a huge undertaking. There > should be some prototyping done by an energetic volunteer. > > There are rumors that moc generated code leads to some issues here. > > How will `QT_CONFIG()` macros work together with modules? Every > permutation would need to be shipped as a separate module. But they > are going to be constant within a built Qt. Not something the user of > the library can change. > > Modules are not supported by build systems (including qmake and CMake) > yet. CMake developer Kitware is working on it, though. > > > ## Coroutines (C++20) > > QDialog::call/exec() are already coroutines, but stackful ones. So > converting to them stackless is not really possible. But there might > be better candidates in networking or elsewhere with callbacks. > > Standard coroutines are quite cumbersome to use. Would we use an > external helper library with that or would Qt provide their own helper > for coroutines? Having Qt-friendly coroutine helpers would be nice. > > Test data supplying is currently a huge matrix of QVariants and is > actually a performance bottleneck for our tests. Using generators for > these might be helpful? They are not going to make a difference > compared to a good hand-written generator. So the performance issues > might be fixed with other approaches. > > > # Library > > Contributions to any of these would be welcome. > > > ## std::any > > std::any is like a QVariant that does not need registration. > > Could there be conversions between QVariant and std::any? Ville is > skeptical about how to do that. Olivier suggested adding support for > conversion from std::any to QVariant into QMetatype. But can that be > done with just a reference to `std::type_info`? > > std::any is a replacement for void\*. It knows the type that it holds. > > > ## std::filesystem > > Giuseppe: Should be use std::filesystem::path types consistently in > our APIs instead of QString? Ville: There should be a prototype patch > to see how big the effect is. I'm concerned that the impact would be > too big. > > Is std::filesystem::path API stable enough? Standard committee cares > about API stability a lot, so that's not a worry. Although some want a > new version of the API that uses std::expected. > > > ## Parallel STL algorithms > > We could allow parallel execution tags in our API to let users ask for > use of parallel algorithms. > > But what are the places in Qt API that actually need these? More data > analysis stuff (if developed) would find it helpful. But often users > get to choose their own algorithms and so can use parallel algorithms > without our containers needing to know about it. > > If a parallel STL implementation is not available, falling back to > single-threaded implementation is always an option. So support could > be utilized only when available and not demanded from all platforms. > Or the platfrom support can be a shim that still always processes > everything without parallelism. > > > ## `std::unique_ptr` > > Better support for `std::unique_ptr` for Qt APIs? > > A patch for more explicit ownership for QObject hierarchy has been > suggested in the past. Maybe out of scope for this session. > `std::unique_ptr` is not new in C++17. > > > ## std::optional > > Would it be worth changing API to return std::optionals instead of > bool output parameters? It would be a big source-incompatible change. > > > ## `std::string_view` > > Do we want to use `std::string_view`? Or do we need a QByteArrayView? > In order to match QByteArray API? > > Will QByteArray still be for string data in Qt 6? That's a topic for > tomorrows session. > > QByteArray has some API that expects the contents to be string-like. > Unfortunately, because they don't really belong there. QByteArray's > future should be clarified before making decisions about these can be > made. > > > ## std::format (C++20) > > Not available to us yet. And will work with `std::basic_string` only > pretty much. Not with QString. > > > # Co-operation with compiler vendors > > Ville has talked to INTEGRITY multiple times. Technically they can > provide a C++17 compatible compiler due to using IDG frontend. They > haven't provided a timeline when that is actually released. > > Embedded (and other) platforms that don't provide C++17 launch will be > initially dropped from being supported. They will be added later once > their compilers catch up. > > QNX has gcc-based compiler so they should also be able to update their > systems. > > > # Testing > > Testlib feels old and unfriendly. Reflection is the real killer > feature for nice testing. It would allow much less macro use and other > boilerplate. It's also the solution for everything else. > > > # Getting rid of moc > > Reflection should also replace moc at some point. > > Andrew (one of the reflection proposal authors) is working on > something very moc-like and would like feedback from the Qt community. > So far he has not gotten any. People who know our metaobject system > well should engage with standard committee members so that the final > reflection solution will serve us well. Ville Voutilainen is one > possible contact point in addition to Andrew Sutton. > > > # Replacing conditional compilation flags with if constexpr > > if constexpr demands that all branches are valid. Other branch can > only not compile when it is inside a template. > > Conditional compilation still needs the preprocessor, because if a > feature is disabled, the branch using it would not be valid code. > > > # Minimum compiler versions for 6.0 > > Lars had a proposal on the mailing list and there has been no > opposition. > > The set of minimum versions would be: > > - GCC 9 > - Clang 9 > - Apple Clang 11 (Clang 9) > - MSVC 2019 > > Thiago would like it to be a bit more conservative. But when 6.0 comes > out, GCC 9 will be one and a half years old. So it's not bleeding > edge. 18 months old compilers should be fine, but probably not much > newer than that. > > Qt 6 will require C++17. So compiler will be need to switched to C++17 > mode. But users might still be able to have codebases that only use > C++11, since not much API will necessarily require C++17 features to > use. So codebases with compatibility for older language versions (in > other builds) should be largely possible. > > > > Very useful for our containers. > > > ## Fold expressions > > Shortcut for handling parameter packs of vadiadic templates. No need > to write recursive template helpers. > > > ## Inline variable > > Volker: What is the impact of using inline variables to static data > initialization? How do we deal with `Q_GLOBAL_STATIC`? > > Inline variables are safer than static globals. Compiler and linker > guarantee that there will be just one definition. > > `Q_GLOBAL_STATIC` still provides lazy initialization. So inline > variables are not a full replacement. Any big globals that aren't > necessarily used should be gated by lazy initialization to avoid > constructing them unnecessarily. > > > ## Polymorphic lambdas > > What is it? It has auto as its parameter type. So the same lambda can > be used with multiple invocations with parameters of different types. > > Most common use is just for brevity. It gives you perfect forwarding > as well, if you use auto && as the type. > > But these are not API visible, just perhaps useful inside the > implementation. > > > ## Structured bindings > > QRect and QPoint might be possible candidates. But there will not be > many that this makes sense for. > > Some of these will already be aggregates and work automatically. But > perhaps they for example have user-defined constructors and so don't > fulfill the requirements of that. > > > ## Language attributes > > There are macros for many standard attributes, like nodiscard, > deprecated, fallthrough, likely and unlikely. > > When is the right point to remove this macros and use the attributes > directly? When all compilers support it. Although that causes pain > when backporting to older branches. > > That applies to all language features, though. Some backporting is > really hairy, like converting if constexpr solutions back to template > specializations. > > > ## Modules (C++20) > > Properly modularizing Qt is going to be a huge undertaking. There > should be some prototyping done by an energetic volunteer. > > There are rumors that moc generated code leads to some issues here. > > How will `QT_CONFIG()` macros work together with modules? Every > permutation would need to be shipped as a separate module. But they > are going to be constant within a built Qt. Not something the user of > the library can change. > > Modules are not supported by build systems (including qmake and CMake) > yet. CMake developer Kitware is working on it, though. > > > ## Coroutines (C++20) > > QDialog::call/exec() are already coroutines, but stackful ones. So > converting to them stackless is not really possible. But there might > be better candidates in networking or elsewhere with callbacks. > > Standard coroutines are quite cumbersome to use. Would we use an > external helper library with that or would Qt provide their own helper > for coroutines? Having Qt-friendly coroutine helpers would be nice. > > Test data supplying is currently a huge matrix of QVariants and is > actually a performance bottleneck for our tests. Using generators for > these might be helpful? They are not going to make a difference > compared to a good hand-written generator. So the performance issues > might be fixed with other approaches. > > > # Library > > Contributions to any of these would be welcome. > > > ## std::any > > std::any is like a QVariant that does not need registration. > > Could there be conversions between QVariant and std::any? Ville is > skeptical about how to do that. Olivier suggested adding support for > conversion from std::any to QVariant into QMetatype. But can that be > done with just a reference to `std::type_info`? > > std::any is a replacement for void\*. It knows the type that it holds. > > > ## std::filesystem > > Giuseppe: Should be use std::filesystem::path types consistently in > our APIs instead of QString? Ville: There should be a prototype patch > to see how big the effect is. I'm concerned that the impact would be > too big. > > Is std::filesystem::path API stable enough? Standard committee cares > about API stability a lot, so that's not a worry. Although some want a > new version of the API that uses std::expected. > > > ## Parallel STL algorithms > > We could allow parallel execution tags in our API to let users ask for > use of parallel algorithms. > > But what are the places in Qt API that actually need these? More data > analysis stuff (if developed) would find it helpful. But often users > get to choose their own algorithms and so can use parallel algorithms > without our containers needing to know about it. > > If a parallel STL implementation is not available, falling back to > single-threaded implementation is always an option. So support could > be utilized only when available and not demanded from all platforms. > Or the platfrom support can be a shim that still always processes > everything without parallelism. > > > ## `std::unique_ptr` > > Better support for `std::unique_ptr` for Qt APIs? > > A patch for more explicit ownership for QObject hierarchy has been > suggested in the past. Maybe out of scope for this session. > `std::unique_ptr` is not new in C++17. > > > ## std::optional > > Would it be worth changing API to return std::optionals instead of > bool output parameters? It would be a big source-incompatible change. > > > ## `std::string_view` > > Do we want to use `std::string_view`? Or do we need a QByteArrayView? > In order to match QByteArray API? > > Will QByteArray still be for string data in Qt 6? That's a topic for > tomorrows session. > > QByteArray has some API that expects the contents to be string-like. > Unfortunately, because they don't really belong there. QByteArray's > future should be clarified before making decisions about these can be > made. > > > ## std::format (C++20) > > Not available to us yet. And will work with `std::basic_string` only > pretty much. Not with QString. > > > # Co-operation with compiler vendors > > Ville has talked to INTEGRITY multiple times. Technically they can > provide a C++17 compatible compiler due to using IDG frontend. They > haven't provided a timeline when that is actually released. > > Embedded (and other) platforms that don't provide C++17 launch will be > initially dropped from being supported. They will be added later once > their compilers catch up. > > QNX has gcc-based compiler so they should also be able to update their > systems. > > > # Testing > > Testlib feels old and unfriendly. Reflection is the real killer > feature for nice testing. It would allow much less macro use and other > boilerplate. It's also the solution for everything else. > > > # Getting rid of moc > > Reflection should also replace moc at some point. > > Andrew (one of the reflection proposal authors) is working on > something very moc-like and would like feedback from the Qt community. > So far he has not gotten any. People who know our metaobject system > well should engage with standard committee members so that the final > reflection solution will serve us well. Ville Voutilainen is one > possible contact point in addition to Andrew Sutton. > > > # Replacing conditional compilation flags with if constexpr > > if constexpr demands that all branches are valid. Other branch can > only not compile when it is inside a template. > > Conditional compilation still needs the preprocessor, because if a > feature is disabled, the branch using it would not be valid code. > > > # Minimum compiler versions for 6.0 > > Lars had a proposal on the mailing list and there has been no > opposition. > > The set of minimum versions would be: > > - GCC 9 > - Clang 9 > - Apple Clang 11 (Clang 9) > - MSVC 2019 > > Thiago would like it to be a bit more conservative. But when 6.0 comes > out, GCC 9 will be one and a half years old. So it's not bleeding > edge. 18 months old compilers should be fine, but probably not much > newer than that. > > Qt 6 will require C++17. So compiler will be need to switched to C++17 > mode. But users might still be able to have codebases that only use > C++11, since not much API will necessarily require C++17 features to > use. So codebases with compatibility for older language versions (in > other builds) should be largely possible. > -- Kari _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development