On Fri, 22 Feb 2019 at 16:05, Vinnie Falco via Boost wrote:

On Fri, Feb 22, 2019 at 5:58 AM Siddhartha Sen wrote:

...

Thanks for the feedback! But what if I focus on C++14 then? Is that a good idea?

Well, look at the survey that I sent you and you tell me.

Interestingly, the ratio C++03 to C++98 is approx. the same as C++14 to C++11, both of those [C++03 and C++14] were bug-fix-std's. Do people report the right thing? Unknown makes unloved, I've only starting seriously diggin' into C++17 and there's no going back, ever, can't wait for 2020. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

On Fri, 22 Feb 2019 at 16:34, Vinnie Falco wrote:

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*

On Fri, 22 Feb 2019 at 16:58, Vinnie Falco wrote:

...

I see where you're coming from [a good place], but just look at stuff

On Fri, Feb 22, 2019 at 6:51 AM degski wrote: like

...

https://github.com/serge-sans-paille/frozen or https://github.com/gnzlbg/static_vector , that's cool stuff..

Yes it is cool, but of no use to C++11 users.

That's why they should become C++17 users.

Also, don't forget the parallel constructs, who needs omp:

I agree here, but there is no reason why this can't be a conditionally enabled feature which is available only under cxx-new. It doesn't imply that the entire library should require cxx-new.

There goes up your maintenance burden and somewhere it will bite.

You're kiddin', right?

No.

Didn't think you were.

constexpr if

This is a convenience to the author but doesn't directly benefit users. The same result can be achieved in C++11, but with more code.

TMP, sure, but it's complex and hell to debug. You should not see those features in isolation as you seem to do, it's when you combine them, the constexpr if, the constexpr lambda's etc, the sum is more than the individual bits. Boost.Variant works in C++11

...

any, optional

Both are available in Boost, in C++11

I did not miss that, but I prefer the version maintained by my library supplier, he/she makes sure it works correctly with the rest of my STL.

...

lamda capture of 'this' (very handy),

Can be accomplished by expression the lambda as a class.

Or by typing this in the capture list, what's easier?

Yes, I hear your argument. But I do think that for something new,

...

C++14 would be a better start

I disagree. C++14 is a pointless update. Either go C++11, or go C++17.

Maybe, whether it's pointless I'm not capable of judging, I must admit I never noticed C++14 (I did, unknowingly, use features of it, though), but I'd vote for C++17, then. We can just conclude [let's do that] that we are coming from different directions. The sales-argument seems important to you, I don't need to sell anything. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*