Feature freeze C ++ 20. Coroutines, Modules and more

    The other day there was a meeting of the international standardization committee C ++ in the American city of Kona. It was not just a meeting, but a feature freeze! No serious new ideas can seep into the standard anymore, there are only a couple of meetings left to add pre-approved things, correct deficiencies and eliminate roughnesses.

    Should Modules and Corutins be expected in C ++ 20, will there be a fast library for formatting the output, will it be able to work with calendars, will they add std :: stacktrace , will the compiler start calling std :: move itself in some cases, will they accept std :: flat_map ? All this and much more awaits you under the cut.



    Coroutines TS


    The hottest debate erupted around coroutines. The committee had to consider three different approaches to coroutines and decide whether to accept the existing Coroutines TS as a standard, or take a different path.

    The choice was not easy, each approach has its disadvantages and advantages:

    • N4775 :
      • + there are no restrictions on the fact that coroutines should be described in the header file
      • - there are no strict guarantees that there will be no dynamic allocation
      • ± not the easiest interface ( P1477R0 fixes this)
      • - ugly keywords co_await and co_yield (sentence P1485R0 from WP21 fixes this)
      • + 3 years applied in practice

    • P1063R2 :
      • + no dynamic allocations
      • - coroutines must be described in the header file or you need to trick yourself with type erasure yourself
      • - even more scary key operators [<-] and [->]
      • - no working prototype
      • - not the easiest interface for creating asynchronous things

    • P1430R0 :
      • + no dynamic allocations
      • - coroutines must be described in the header file or you need to slyly get out with type erasure yourself
      • + no scary keywords, everything is smooth
      • + Corutin users do not see scary coroutine insides (do not even see co_await analogues, everything works out of the box)
      • - the first proposal, has never been discussed, requires a bunch of improvements
      • - it is impossible to implement on current technologies (require support for dynamic-sized structures), require huge labor costs to implement
      • ± a bit like callback noodles


    After much debate, coroutines were adopted in C ++ 20 as they were in Coroutines TS (with co_ * prefixes and old customization points).

    Modules


    The discussion of modules was influenced by one interesting document with performance measurements:
    P1441R0 . The results can be interpreted in different ways: from "existing assembly systems and implementation of modules are not yet optimized enough" to "modules do not scale well with the increasing complexity of the project."

    In addition to this document, the committee discussed a number of minor changes to the current modules. As a result, after 15 years of discussion, prototyping and experimentation with implementations, the modules were adopted in C ++ 20.

    Format


    Good news everyone! If you find no fatal flaws in the Library subgroup, then in C ++ 20 it will be possible to format strings safely and very quickly. Say goodbye to std :: ios , std :: locale and the other horrors of the 90s! Python now has a similar syntax for formatting out of the box in C ++: P0645R5 .

    Moreover, the proposal to integrate the new formatting and calendar times P1361R0 was accepted . If everything goes according to plan, then the dates can be displayed in a human way!

    Networking, Executors, and Properties


    Executors are an important brick for supporting Networking in C ++ out of the box. Executors need Properties - the ability to modify the data type, depending on the parameter passed at the compilation stage, without changing the concept of the type.

    Properties are described in P1393R0 . Despite the fact that the text for inclusion in the standard is only a couple of pages, the proposal caused heated discussions. The proposal allows you to make almost omnipotent customization points, change the behavior of any functions using Properties.

    As a result, it was decided to include Properties in the language only in C ++ 23, and accordingly, Executors and Networking in C ++ 20 will not appear.

    Other


    The following changes have already been made to the C ++ 20 draft:

    • Structures without constructors (aggregates) can now be initialized using P0960 parentheses . In practice, this means that now std :: make_shared , std :: make_unique , std :: * :: emplace * will work correctly with aggregates without compilation errors
    • Lerp functions for linear interpolation P0811 have been added
    • Added the ability to vectorize the algorithms of the standard library P1001
    • The std :: span methods now return unsigned types (similar to the whole standard library) + the std :: ssize function was added to get the size of the container as a signed number P1227
    • Unordered containers learned how to look up values ​​using a pre-calculated hash of P0920

    Many other things await the final review in the Library and Core subgroups for inclusion in C ++ 20:

    • Effective wait on std :: atomic; semaphore and barrier classes P1135
    • std :: flat_map P0429
    • std :: flat_set P1222
    • std :: function_ref P0792
    • constexpr for and P0533
    • std :: ranges :: to <any-container> for storing a range of values ​​in a P1206 container
    • The ability to efficiently extract strings from std :: * stringstream and transfer custom strings P0408
    • Multiple edits for operator <=> , ranges, constexpr

    Merits of RG21


    On the very first day, Core subgroup took up the dearly beloved Yandex.Taxi proposal for the Stacktrace P0881R3 . Design comments were further discussed in the LEWG subgroup, once again worked out in Core. As a result, corrections were made throughout the week and discussions were held. The proposal is not yet included in the draft standard, but it should be in C ++ 20 (if they suddenly find some fatal flaw).

    Before discussing our idea of P1485R0 to bring keywords for coroutine, it did not come to a conclusion.

    Also in SG1, Concurrency discussed the idea of ​​a concurrent unordered map P0652R2. We were asked to double-check that the proposed API avoids reader contention. They also said to investigate concurrent unordered containers that do not have the erase function and do not protect the value of the container from competitive modification.

    The offer from ZaMaZaN4iK to specialize std :: hash for various classes of the standard library P1406R0 was decided to be severely cut. The committee recommended leaving specializations only for std :: pair , std :: tuple , std :: array and std :: basic_string from user allocators.

    In the subgroup of numbers SG6, a mechanism was discussed for the interaction of various new classes of numbers P0880R2. The proposal allows you to specialize two templates, get a complete set of mathematical operations and comparisons for all new types. Following the discussion, they decided to try to expand the mechanism so that it could be used not only for the needs of the standard library, but also users could use these operators for their types.

    We also discussed our minor suggestions, including feature testing macro P1424R0 and policies for adding them to the standard.

    We quickly discussed our idea of ​​allowing the compiler to remove unnecessary copies of R0889R1 . We were told to continue work in this direction and threw examples that should not break with the new rules.

    Instead of totals


    C ++ 20 will be just as dramatically different from C ++ 17 as C ++ 11 will be different from C ++ 03. A huge number of new technologies and new paradigms: Concepts, Contracts, Ranges, Modules, Coroutines, constexpr containers and constexpr dynamic polymorphism, nibloids, etc.

    Soon, we, Working Group 21, will send comments to the draft C ++ standard 20. Therefore, if you have any pain or you do not agree with any innovation, please leave your thoughts on this page .

    The next meeting of the international committee will be in the summer, at which innovations for C ++ 23 may begin to be considered. If you want to change something in C ++ or offer your idea, you can always write at https://stdcpp.ru/where people from WP21 will help you convey your desires to the committee.

    Would you like to talk to us live? An open meeting of RG21 will be held soon, stay tuned for announcements at events.yandex.ru . Also look for us at the April C ++ Russia conference in Moscow.

    Only registered users can participate in the survey. Please come in.

    Which of C ++ 20 is most useful for you in development?

    • 9.1% Concepts 30
    • 5.7% Contracts 19
    • 36.2% Modules 119
    • 23.7% Coroutines 78
    • 7.3% Everything related to constexpr 24
    • 10.9% Ranges 36
    • 6.7% Other standard library news 22

    Also popular now: