lerp() noexcept is now required, so we should remove comments

[dtoma]

Description

Remove /* strengthened*/ comments now that noexcept is required by the standard.

Fixes #530

Checklist

Be sure you've read README.md and understand the scope of this repo.

If you're unsure about a box, leave it unchecked. A maintainer will help you.

• Identifiers in product code changes are properly _Ugly as per
  https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
• The STL builds successfully and all tests have passed (must be manually
  verified by an STL maintainer before automated testing is enabled on GitHub,
  leave this unchecked for initial submission).
• These changes introduce no known ABI breaks (adding members, renaming
  members, adding virtual functions, changing whether a type is an aggregate
  or trivially copyable, etc.).
• These changes were written from scratch using only this repository,
  the C++ Working Draft (including any cited standards), other WG21 papers
  (excluding reference implementations outside of proposed standard wording),
  and LWG issues as reference material. If they were derived from a project
  that's already listed in NOTICE.txt, that's fine, but please mention it.
  If they were derived from any other project (including Boost and libc++,
  which are not yet listed in NOTICE.txt), you must mention it here,
  so we can determine whether the license is compatible and what else needs
  to be done.

[StephanTLavavej]

Thanks for taking care of this! Perhaps surprisingly, removing these comments is causing our pull request checks to fail. That's because we run clang-format on the STL's product and test code (making it easy to have consistently formatted code without a lot of human review and intervention), and our checks verify that clang-format doesn't want to change any files.

In this case, the /* strengthened */ comments were causing clang-format to wrap long lines; we have a column limit of 120 here:

STL/.clang-format

Line 85 in 02043f8

ColumnLimit: 120

By removing the comments, some of these lines now fit in 120 columns, so clang-format wants to unwrap them.

You can fix this by running clang-format 9 on this file (Clang 10 was just released, with different clang-format behavior; we'll be updating to that soon but not yet). This would be important for large-scale changes, or future pull requests. Alternatively, a quick way to fix this PR is to look at the failing checks, which we've configured to print the changes that clang-format wants to make, and just manually unwrap the affected lines. We run clang-format as part of the x64 build, so you can click on the "Details" next to the "microsoft.STL (x64)" checks at the bottom of the PR; that will take you to https://github.com/microsoft/STL/pull/640/checks?check_run_id=535466270 which shows that the float and double overloads should be unwrapped. (Alas, long double is verbose enough to still require wrapping.)

You can even configure your editor to automatically run clang-format; if you use VSCode with Microsoft's C/C++ Extension, then opening the repo's folder will pick up our "format on save" setting:

STL/.vscode/settings.json

Line 5 in 02043f8

"editor.formatOnSave": true,

Who would have expected that removing 3 comments could be so complicated? 😹

[dtoma]

Thanks for the very detailed comment! In this kind of case, do you prefer amending/force pushing the commit, or adding a new commit with the fixed formatting?

[StephanTLavavej]

Thanks for asking! Adding a new commit makes reviewing easier, since GitHub provides UI to see "changes since your last review". When we merge pull requests, we choose to squash each PR into a single commit for tidy linear history, so it won't affect what goes into the repo history.

[StephanTLavavej]

😸

[CaseyCarter]

@dtoma FYI I've merged master into your branch to resolve a merge conflict with #645.

[dtoma]

Thanks! Should I run clang-format 10.0 from now on?

[CaseyCarter]

Thanks! Should I run clang-format 10.0 from now on?

Yes - clang-format 10 is now the gold standard.

[cbezault]

Thanks for the contribution!