Page 105 noexcept potential fallacy on note section

[dmgolembiowski]

Thank you, @emdeleo!

Marking a function noexcept enables some code optimizations that rely on the function's not being able to throw an excpetion. Essentially, the compiler is liberated to use move semantics, which may be faster ... (Ch. 4 p. 105)

I think this might be incorrect -- it approximates the "Things to Remember" section from Item 14, and potentially conveys the wrong message in a subtle way. noexcept's inclusion in a function's interface -- when pulled in by client code -- isn't looking the compile-time optimization by its inclusion but (I believe) for a compile-time guarantee that an exception isn't possible.

The note on optimizeability is still a great inclusion, but I think two ideas here were squished together and changed the original meaning.

(Source:)

Things to Remember

• noexcept is part of a function's interface, and that means that callers may depend on it.
• noexcept functions are more optimizable than non-noexcept` functions.
  ...

Originally posted by @dmgolembiowski in #32 (comment)

[JLospinoso]

Thanks for your comment! Yes, it is very close to Scott's comments on noexcept. Could you help me understand your comment "isn't looking the compile-time optimization by its inclusion"?