Summary

I'm seeking comments on the following questions

1. Should LightGBM support the C++17 standard for all components?

2. If yes, should it continue to default to the C++11 standard?

By "support", I mean "have at least one CI job testing LightGBM compiled with C++17 standard on Mac (clang), Linux (non-CUDA w/ gcc, CUDA with nvcc), and Windows (MINGW and MSVC)".

Motivation

CRAN might force the R package to upgrade to that standard soon (see the proposal in #5690).

Beyond just R, though, there are other new language features LightGBM might benefit from in C++17

• https://en.cppreference.com/w/cpp/17
• https://lhcb.github.io/developkit-lessons/first-development-steps/05c-cpp17.html
• https://www.oreilly.com/content/c17-upgrades-you-should-be-using-in-your-code/

Can LightGBM's vendored dependencies be compiled with the C++17 standard?

Yes! See the passing CI jobs in #5690, plus the following links.

• Boost: C++03 (via backports), C++11 (full), with support for some C++14 and C++17 features (docs link)
• Eigen: C++17 (docs link, code link)
• fast_double_parser: C++11 (code link)
• fmt: C++11, C++14, C++17, C++20 (docs link)

If C++17 became the default, what range of compiler versions would LightGBM work with?

• gcc >= 5 (October 2017, supporting docs)
• clang >= 5 (September 2017, supporting docs)
• MSVC >= 2019 (April 2019, supporting docs)
• nvcc in CUDA 11+ (May 2020, supporting docs)

Reviewers

Tagging in maintainers and other contributors who I feel might have an opinion on this, and who are probably more knowledgeable about this than me.

@shiyu1994 @guolinke @StrikerRUS @jmoralez @btrotta @Laurae2 @huanzhang12 @imatiach-msft @AlbertoEAF @lemire @trivialfis @hcho3 @ChipKerchner @cyfdecyf

Thanks all for your time and consideration!