Why is std::move not [[nodiscard]] in C++20? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Data science time! April 2019 and salary with experience The Ask Question Wizard is Live!Why can templates only be implemented in the header file?Why is “using namespace std” considered bad practice?What are move semantics?Why are elementwise additions much faster in separate loops than in a combined loop?Why is reading lines from stdin much slower in C++ than Python?Why is it faster to process a sorted array than an unsorted array?Why should I use a pointer rather than the object itself?enum to string in modern C++11 / C++14 / C++17 and future C++20Why is `std::reference_wrapper` deprecated in c++17 and removed in c++20?Why use std::make_unique in C++17?

What does Turing mean by this statement?

If Windows 7 doesn't support WSL, then what is "Subsystem for UNIX-based Applications"?

Drawing a ribbon graph

"klopfte jemand" or "jemand klopfte"?

Is multiple magic items in one inherently imbalanced?

Test print coming out spongy

What is the difference between a "ranged attack" and a "ranged weapon attack"?

Is openssl rand command cryptographically secure?

What is the origin of 落第?

How many morphisms from 1 to 1+1 can there be?

Putting class ranking in CV, but against dept guidelines

How do living politicians protect their readily obtainable signatures from misuse?

How many time has Arya actually used Needle?

How could we fake a moon landing now?

Why is it faster to reheat something than it is to cook it?

Tannaka duality for semisimple groups

Google .dev domain strangely redirects to https

What to do with repeated rejections for phd position

Why is std::move not [[nodiscard]] in C++20?

Why not send Voyager 3 and 4 following up the paths taken by Voyager 1 and 2 to re-transmit signals of later as they fly away from Earth?

Does any scripture mention that forms of God or Goddess are symbolic?

How to ternary Plot3D a function

How does the math work when buying airline miles?

Asymptotics question



Why is std::move not [[nodiscard]] in C++20?



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Data science time! April 2019 and salary with experience
The Ask Question Wizard is Live!Why can templates only be implemented in the header file?Why is “using namespace std” considered bad practice?What are move semantics?Why are elementwise additions much faster in separate loops than in a combined loop?Why is reading lines from stdin much slower in C++ than Python?Why is it faster to process a sorted array than an unsorted array?Why should I use a pointer rather than the object itself?enum to string in modern C++11 / C++14 / C++17 and future C++20Why is `std::reference_wrapper` deprecated in c++17 and removed in c++20?Why use std::make_unique in C++17?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








12















I've recently read about [[nodiscard]] in C++17, and as far as I understand it's a new feature (design by contract?) which forces you to use the return value. This makes sense for controversial functions like std::launder (nodiscard since C++20), but I wonder why std::move isn't defined like so in C++17/20. Do you know a good reason or is it because C++20 isn't finalised yet?






c++ language-lawyer c++17 c++20







share|improve this question



















  • 1





    I know a reason that makes sense to me, but unless there's an official document explicitly saying why it isn't, that just turns the question to be opinion-based.

    – Sebastian Redl
    9 hours ago











  • Why do you think it's not necessary for std::move to be [[nodiscard]]?

    – bbalchev
    9 hours ago






  • 4





    Because absolutely nothing bad (or at all) happens when you don't use it.

    – Sebastian Redl
    9 hours ago






  • 3





    @SebastianRedl: similarly, nothing useful happens. It's the same as writing an empty statement, so [[nodiscard]] would help diagnose bugs. Also, nothing bad happens when vector::empty() is ignored, but that is marked [[nodiscard]] for obvious reasons.

    – Vittorio Romeo
    8 hours ago






  • 1





    @SebastianRedl That sounds like a great reason to mark it [[nodiscard]]: "Hey, you did something completely pointless. Did you mean to do something else?"

    – Barry
    42 mins ago

















12















I've recently read about [[nodiscard]] in C++17, and as far as I understand it's a new feature (design by contract?) which forces you to use the return value. This makes sense for controversial functions like std::launder (nodiscard since C++20), but I wonder why std::move isn't defined like so in C++17/20. Do you know a good reason or is it because C++20 isn't finalised yet?






c++ language-lawyer c++17 c++20







share|improve this question



















  • 1





    I know a reason that makes sense to me, but unless there's an official document explicitly saying why it isn't, that just turns the question to be opinion-based.

    – Sebastian Redl
    9 hours ago











  • Why do you think it's not necessary for std::move to be [[nodiscard]]?

    – bbalchev
    9 hours ago






  • 4





    Because absolutely nothing bad (or at all) happens when you don't use it.

    – Sebastian Redl
    9 hours ago






  • 3





    @SebastianRedl: similarly, nothing useful happens. It's the same as writing an empty statement, so [[nodiscard]] would help diagnose bugs. Also, nothing bad happens when vector::empty() is ignored, but that is marked [[nodiscard]] for obvious reasons.

    – Vittorio Romeo
    8 hours ago






  • 1





    @SebastianRedl That sounds like a great reason to mark it [[nodiscard]]: "Hey, you did something completely pointless. Did you mean to do something else?"

    – Barry
    42 mins ago













12












12








12


1






I've recently read about [[nodiscard]] in C++17, and as far as I understand it's a new feature (design by contract?) which forces you to use the return value. This makes sense for controversial functions like std::launder (nodiscard since C++20), but I wonder why std::move isn't defined like so in C++17/20. Do you know a good reason or is it because C++20 isn't finalised yet?






c++ language-lawyer c++17 c++20







share|improve this question
















I've recently read about [[nodiscard]] in C++17, and as far as I understand it's a new feature (design by contract?) which forces you to use the return value. This makes sense for controversial functions like std::launder (nodiscard since C++20), but I wonder why std::move isn't defined like so in C++17/20. Do you know a good reason or is it because C++20 isn't finalised yet?






c++ language-lawyer c++17 c++20




c++ language-lawyer c++17 c++20






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 14 mins ago







bbalchev

















asked 9 hours ago









bbalchevbbalchev

2771315




2771315







  • 1





    I know a reason that makes sense to me, but unless there's an official document explicitly saying why it isn't, that just turns the question to be opinion-based.

    – Sebastian Redl
    9 hours ago











  • Why do you think it's not necessary for std::move to be [[nodiscard]]?

    – bbalchev
    9 hours ago






  • 4





    Because absolutely nothing bad (or at all) happens when you don't use it.

    – Sebastian Redl
    9 hours ago






  • 3





    @SebastianRedl: similarly, nothing useful happens. It's the same as writing an empty statement, so [[nodiscard]] would help diagnose bugs. Also, nothing bad happens when vector::empty() is ignored, but that is marked [[nodiscard]] for obvious reasons.

    – Vittorio Romeo
    8 hours ago






  • 1





    @SebastianRedl That sounds like a great reason to mark it [[nodiscard]]: "Hey, you did something completely pointless. Did you mean to do something else?"

    – Barry
    42 mins ago












  • 1





    I know a reason that makes sense to me, but unless there's an official document explicitly saying why it isn't, that just turns the question to be opinion-based.

    – Sebastian Redl
    9 hours ago











  • Why do you think it's not necessary for std::move to be [[nodiscard]]?

    – bbalchev
    9 hours ago






  • 4





    Because absolutely nothing bad (or at all) happens when you don't use it.

    – Sebastian Redl
    9 hours ago






  • 3





    @SebastianRedl: similarly, nothing useful happens. It's the same as writing an empty statement, so [[nodiscard]] would help diagnose bugs. Also, nothing bad happens when vector::empty() is ignored, but that is marked [[nodiscard]] for obvious reasons.

    – Vittorio Romeo
    8 hours ago






  • 1





    @SebastianRedl That sounds like a great reason to mark it [[nodiscard]]: "Hey, you did something completely pointless. Did you mean to do something else?"

    – Barry
    42 mins ago







1




1





I know a reason that makes sense to me, but unless there's an official document explicitly saying why it isn't, that just turns the question to be opinion-based.

– Sebastian Redl
9 hours ago





I know a reason that makes sense to me, but unless there's an official document explicitly saying why it isn't, that just turns the question to be opinion-based.

– Sebastian Redl
9 hours ago













Why do you think it's not necessary for std::move to be [[nodiscard]]?

– bbalchev
9 hours ago





Why do you think it's not necessary for std::move to be [[nodiscard]]?

– bbalchev
9 hours ago




4




4





Because absolutely nothing bad (or at all) happens when you don't use it.

– Sebastian Redl
9 hours ago





Because absolutely nothing bad (or at all) happens when you don't use it.

– Sebastian Redl
9 hours ago




3




3





@SebastianRedl: similarly, nothing useful happens. It's the same as writing an empty statement, so [[nodiscard]] would help diagnose bugs. Also, nothing bad happens when vector::empty() is ignored, but that is marked [[nodiscard]] for obvious reasons.

– Vittorio Romeo
8 hours ago





@SebastianRedl: similarly, nothing useful happens. It's the same as writing an empty statement, so [[nodiscard]] would help diagnose bugs. Also, nothing bad happens when vector::empty() is ignored, but that is marked [[nodiscard]] for obvious reasons.

– Vittorio Romeo
8 hours ago




1




1





@SebastianRedl That sounds like a great reason to mark it [[nodiscard]]: "Hey, you did something completely pointless. Did you mean to do something else?"

– Barry
42 mins ago





@SebastianRedl That sounds like a great reason to mark it [[nodiscard]]: "Hey, you did something completely pointless. Did you mean to do something else?"

– Barry
42 mins ago












2 Answers
2






active

oldest

votes


















6














AFAIK P0600R1 is the only proposal for adding [[nodiscard]] to the standard library that was applied to C++20. From that paper:




We suggest a conservative approach:



[...]



It should not be added when:



  • [...]

  • not using the return value makes no sense but doesn’t hurt and is usually not an error

  • [...]

So, [[nodiscard]] should not signal bad code if this



  • [...]

  • doesn’t hurt and probably no state change was meant that doesn’t happen



So the reason is that the standard library uses a conservative approach and a more aggresive one is not yet proposed.






share|improve this answer






























    3














    The MSVC standard library team went ahead and added several thousand instances of [[nodiscard]] since VS 2017 15.6, and have reported wild success with it (both in terms of finding lots of bugs and generating no user complaints). The criteria they described were approximately:



    1. Pure observers, e.g. vector::size(), vector::empty, and even std::count_if()

    2. Things that acquire raw resources, e.g. allocate()

    3. Functions where discarding the return value is extremely likely to lead to incorrect code, e.g. std::remove()

    MSVC does mark both std::move() and std::forward() as [[nodiscard]] following these criteria.



    While it's not officially annotated as such in the standard, it seems to provide clear user benefit and it's more a question of crafting such a paper to mark all the right things [[nodiscard]] (again, several thousand instances from MSVC) and apply them -- it's not complex work per se, but the volume is large. In the meantime, maybe prod your favorite standard library vendor and ask them to [[nodiscard]] lots of stuff?




    This makes sense for controversial functions like std::launder




    I'm not sure what "controversial" is doing in there - but given that the entire point of calling launder is to get a new pointer out of it, not using that pointer is clearly a bug -- it fits very nicely into (3) above.






    share|improve this answer























      Your Answer






      StackExchange.ifUsing("editor", function ()
      StackExchange.using("externalEditor", function ()
      StackExchange.using("snippets", function ()
      StackExchange.snippets.init();
      );
      );
      , "code-snippets");

      StackExchange.ready(function()
      var channelOptions =
      tags: "".split(" "),
      id: "1"
      ;
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function()
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled)
      StackExchange.using("snippets", function()
      createEditor();
      );

      else
      createEditor();

      );

      function createEditor()
      StackExchange.prepareEditor(
      heartbeatType: 'answer',
      autoActivateHeartbeat: false,
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader:
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      ,
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      );



      );













      draft saved

      draft discarded


















      StackExchange.ready(
      function ()
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55772424%2fwhy-is-stdmove-not-nodiscard-in-c20%23new-answer', 'question_page');

      );

      Post as a guest















      Required, but never shown

























      2 Answers
      2






      active

      oldest

      votes








      2 Answers
      2






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes









      6














      AFAIK P0600R1 is the only proposal for adding [[nodiscard]] to the standard library that was applied to C++20. From that paper:




      We suggest a conservative approach:



      [...]



      It should not be added when:



      • [...]

      • not using the return value makes no sense but doesn’t hurt and is usually not an error

      • [...]

      So, [[nodiscard]] should not signal bad code if this



      • [...]

      • doesn’t hurt and probably no state change was meant that doesn’t happen



      So the reason is that the standard library uses a conservative approach and a more aggresive one is not yet proposed.






      share|improve this answer



























        6














        AFAIK P0600R1 is the only proposal for adding [[nodiscard]] to the standard library that was applied to C++20. From that paper:




        We suggest a conservative approach:



        [...]



        It should not be added when:



        • [...]

        • not using the return value makes no sense but doesn’t hurt and is usually not an error

        • [...]

        So, [[nodiscard]] should not signal bad code if this



        • [...]

        • doesn’t hurt and probably no state change was meant that doesn’t happen



        So the reason is that the standard library uses a conservative approach and a more aggresive one is not yet proposed.






        share|improve this answer

























          6












          6








          6







          AFAIK P0600R1 is the only proposal for adding [[nodiscard]] to the standard library that was applied to C++20. From that paper:




          We suggest a conservative approach:



          [...]



          It should not be added when:



          • [...]

          • not using the return value makes no sense but doesn’t hurt and is usually not an error

          • [...]

          So, [[nodiscard]] should not signal bad code if this



          • [...]

          • doesn’t hurt and probably no state change was meant that doesn’t happen



          So the reason is that the standard library uses a conservative approach and a more aggresive one is not yet proposed.






          share|improve this answer













          AFAIK P0600R1 is the only proposal for adding [[nodiscard]] to the standard library that was applied to C++20. From that paper:




          We suggest a conservative approach:



          [...]



          It should not be added when:



          • [...]

          • not using the return value makes no sense but doesn’t hurt and is usually not an error

          • [...]

          So, [[nodiscard]] should not signal bad code if this



          • [...]

          • doesn’t hurt and probably no state change was meant that doesn’t happen



          So the reason is that the standard library uses a conservative approach and a more aggresive one is not yet proposed.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered 6 hours ago









          cpplearnercpplearner

          5,87622342




          5,87622342























              3














              The MSVC standard library team went ahead and added several thousand instances of [[nodiscard]] since VS 2017 15.6, and have reported wild success with it (both in terms of finding lots of bugs and generating no user complaints). The criteria they described were approximately:



              1. Pure observers, e.g. vector::size(), vector::empty, and even std::count_if()

              2. Things that acquire raw resources, e.g. allocate()

              3. Functions where discarding the return value is extremely likely to lead to incorrect code, e.g. std::remove()

              MSVC does mark both std::move() and std::forward() as [[nodiscard]] following these criteria.



              While it's not officially annotated as such in the standard, it seems to provide clear user benefit and it's more a question of crafting such a paper to mark all the right things [[nodiscard]] (again, several thousand instances from MSVC) and apply them -- it's not complex work per se, but the volume is large. In the meantime, maybe prod your favorite standard library vendor and ask them to [[nodiscard]] lots of stuff?




              This makes sense for controversial functions like std::launder




              I'm not sure what "controversial" is doing in there - but given that the entire point of calling launder is to get a new pointer out of it, not using that pointer is clearly a bug -- it fits very nicely into (3) above.






              share|improve this answer



























                3














                The MSVC standard library team went ahead and added several thousand instances of [[nodiscard]] since VS 2017 15.6, and have reported wild success with it (both in terms of finding lots of bugs and generating no user complaints). The criteria they described were approximately:



                1. Pure observers, e.g. vector::size(), vector::empty, and even std::count_if()

                2. Things that acquire raw resources, e.g. allocate()

                3. Functions where discarding the return value is extremely likely to lead to incorrect code, e.g. std::remove()

                MSVC does mark both std::move() and std::forward() as [[nodiscard]] following these criteria.



                While it's not officially annotated as such in the standard, it seems to provide clear user benefit and it's more a question of crafting such a paper to mark all the right things [[nodiscard]] (again, several thousand instances from MSVC) and apply them -- it's not complex work per se, but the volume is large. In the meantime, maybe prod your favorite standard library vendor and ask them to [[nodiscard]] lots of stuff?




                This makes sense for controversial functions like std::launder




                I'm not sure what "controversial" is doing in there - but given that the entire point of calling launder is to get a new pointer out of it, not using that pointer is clearly a bug -- it fits very nicely into (3) above.






                share|improve this answer

























                  3












                  3








                  3







                  The MSVC standard library team went ahead and added several thousand instances of [[nodiscard]] since VS 2017 15.6, and have reported wild success with it (both in terms of finding lots of bugs and generating no user complaints). The criteria they described were approximately:



                  1. Pure observers, e.g. vector::size(), vector::empty, and even std::count_if()

                  2. Things that acquire raw resources, e.g. allocate()

                  3. Functions where discarding the return value is extremely likely to lead to incorrect code, e.g. std::remove()

                  MSVC does mark both std::move() and std::forward() as [[nodiscard]] following these criteria.



                  While it's not officially annotated as such in the standard, it seems to provide clear user benefit and it's more a question of crafting such a paper to mark all the right things [[nodiscard]] (again, several thousand instances from MSVC) and apply them -- it's not complex work per se, but the volume is large. In the meantime, maybe prod your favorite standard library vendor and ask them to [[nodiscard]] lots of stuff?




                  This makes sense for controversial functions like std::launder




                  I'm not sure what "controversial" is doing in there - but given that the entire point of calling launder is to get a new pointer out of it, not using that pointer is clearly a bug -- it fits very nicely into (3) above.






                  share|improve this answer













                  The MSVC standard library team went ahead and added several thousand instances of [[nodiscard]] since VS 2017 15.6, and have reported wild success with it (both in terms of finding lots of bugs and generating no user complaints). The criteria they described were approximately:



                  1. Pure observers, e.g. vector::size(), vector::empty, and even std::count_if()

                  2. Things that acquire raw resources, e.g. allocate()

                  3. Functions where discarding the return value is extremely likely to lead to incorrect code, e.g. std::remove()

                  MSVC does mark both std::move() and std::forward() as [[nodiscard]] following these criteria.



                  While it's not officially annotated as such in the standard, it seems to provide clear user benefit and it's more a question of crafting such a paper to mark all the right things [[nodiscard]] (again, several thousand instances from MSVC) and apply them -- it's not complex work per se, but the volume is large. In the meantime, maybe prod your favorite standard library vendor and ask them to [[nodiscard]] lots of stuff?




                  This makes sense for controversial functions like std::launder




                  I'm not sure what "controversial" is doing in there - but given that the entire point of calling launder is to get a new pointer out of it, not using that pointer is clearly a bug -- it fits very nicely into (3) above.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered 43 mins ago









                  BarryBarry

                  187k21331612




                  187k21331612



























                      draft saved

                      draft discarded
















































                      Thanks for contributing an answer to Stack Overflow!


                      • Please be sure to answer the question. Provide details and share your research!

                      But avoid …


                      • Asking for help, clarification, or responding to other answers.

                      • Making statements based on opinion; back them up with references or personal experience.

                      To learn more, see our tips on writing great answers.




                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function ()
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55772424%2fwhy-is-stdmove-not-nodiscard-in-c20%23new-answer', 'question_page');

                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      -