On Fri, 22 Feb 2019 at 16:34, Vinnie Falco
On Fri, Feb 22, 2019 at 6:28 AM degski
wrote: I've only starting seriously diggin' into C++17 and there's no going back, ever, can't wait for 2020.
I would love to use cxx17 and then cxx20, but I value having more users over personal convenience. Rationale: More users equals more testers, more feedback, and a better library, creating a virtuous cycle.
I see where you're coming from [a good place], but just look at stuff like https://github.com/serge-sans-paille/frozen or https://github.com/gnzlbg/static_vector , that's cool stuff. Also, don't forget the parallel constructs, who needs omp: std::for_each ( std::begin ( data_ ), std::end ( data_ ), [ ] ( ) { some lambda } ); ah, I actually wanted it multi-threaded, no worries: std::for_each ( std::execution::par_unseq, std::begin ( data_ ), std::end ( data_ ), [ ] ( ) { some lambda } ); That's powerful stuff [sorry to sound over-enthusiastic]. degski The difference between cxx11 and cxx03 is profound, and justifies
requiring cxx11. However the difference between cxx17 and cxx11 is marginal, especially for a Boost library which already has access to cxx17 types and algorithms through their boost:: equivalents which work in c++11.
You're kiddin', right? constexpr if, fold expressions, structured bindings, variant, any, optional, guaranteed copy elision, lamda capture of 'this' (very handy), constexpr lambdas, attributes, how long do you want me to make this list?
The benefits of cxx17 mostly reside in providing more convenience in the implementation, for example a generic lambda or deduced return type. These are not strictly necessary and don't directly benefit users - I would rather type a bit more than cut off the larger segment of cxx11 and cxx14 people from potential users of my library.
Yes, I hear your argument. But I do think that for something new, C++14 would be a better start [the figures on your quoted survey will move, don't worry]. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*