C++11?

[vinniefalco]

Is C++14 actually needed?

[ckormanyos]

Is C++14 actually needed?

At the moment, yes. Matt (@mborland) can confirm. Now is the time to ask, in the beginning. Some of the planned constexpr-ness would, however, be difficult or not possible with C++11. But I guess you could macro-it-out to const.

Matt?

[mborland]

Internally we use a good swath of the C++14 features:

Binary literals and digit separators: Used consistently in all of the masks needed for construction and manipulation.

Template variables: Used for the standard mathematical constants. Several of the bit masks from above (e.g. inf, nan, etc.) need to be made into template variables as well so we can make the <cmath> functions more generic (e.g. isinf(), isnan(), fpclassifsy(), etc.)

Constexpr: Nothing particularly useful can be done with C++11's constrained definition of constexpr functions. Nearly everything in this library can be constexpr at C++14 so the type can act no different from any built-in.

Externally, Boost.Math's minimum required language standard is C++14. All the functions in that library are generic so long as the type being operated on meets a set of conceptual requirements. The decimal types will meet those requirements, and we can make any minor adjustments required in Math. The killer feature then becomes the end user will get support for all the statistics, interpolation, quadrature, etc. out of the box.

[ckormanyos]

It's worth a second thought though. You can use some BOOST-HAS-constexpr macro all over the place. Then it either will or will-not-be constexpr. Binary constants are trivial. Template variables could be template functions. Stuff like enable_if_t has an equivalent in C++11.

If any clients really want to throw back to 11, now's the time to chek into that.

[vinniefalco]

Internally we use a good swath of the C++14 features:

My opinion:

Users don't care what you use internally as long as the library works. For a C++11 user the library will "not work." It is the job of the library writer to suffer, toil, and invest whatever labor is necessary on behalf of users to deliver a great experience for them.

That said, C++11 is pretty old now and the user base is dwindling, so requiring C++14 is reasonable. But a good principle to adopt is to avoid requiring newer C++ features just because they make the developer's life easier, and do not directly affect how the library is used with respect to the public API.

[ckormanyos]

Users don't care what you use internally as long as the library works. For a C++11 user the library will "not work."

Yes. Does this library have clear client requests for C++11?

That said, C++11 is pretty old now and the user base is dwindling, so requiring C++14 is reasonable. But a good principle to adopt is to avoid requiring newer C++ features just because they make the developer's life easier, and do not directly affect how the library is used with respect to the public API.

I've thought long about this issue. When we jumped up to C++14 (and stopped supporting C++11) in Math and Multiprecision, we had detailed discussions about this. The consensus was to drop C++11 and simply use the added conveneience of C++14.

What I'm missing is a consistent consensus in cppalliance work.

• Do you want to support down to C++11 in all projects?
• Or is C++14 the minimum supported version for cppalliance projects?
• Or is it specifically and openly free to choose the minumum supported C++ versioin for each and every cppalliance library?

At the moment, it seems like the third option is practiced. But that leads us to this discussion.

If the consensus is to port Decimal back to C++11, I could foresee doing this. But I'd say, let's get it in early or soon if it is needed. I believe there could be a reasonable pathway to success for this backport.

I guess what I'm saying is, ... is C++11 needed for Decimal? Yes or no?

[mborland]

I guess what I'm saying is, ... is C++11 needed for Decimal? Yes or no?

I think it is worth getting @glenfe's opinion since he was the one that brought the need for the Decimal library to my attention.

[vinniefalco]

I think it is worth getting @glenfe's opinion

Maybe, but not necessary in this case.

What I'm missing is a consistent consensus in cppalliance work.

There is no consensus and let me clarify: I am not dictating anything. The C++ Alliance does not have a "consensus" or consolidated set of rules for all of its projects. This is intentional. It is up to the staff engineers or volunteers to decide on their project.

Do you want to support down to C++11 in all projects? Or is C++14 the minimum supported version for cppalliance projects?

No, and no.

Or is it specifically and openly free to choose the minumum supported C++ versioin for each and every cppalliance library?

Yes. The choice of C++ version is entirely up to the authors of the library although if a project requires C++20 gratuitously I am going to complain very loudly :)

If the consensus is to port Decimal back to C++11, I could foresee doing this.

No that's not necessary. What I am saying is that working harder by forgoing the conveniences of new C++ features is both a virtue and a principled engineering practice, and we should all embrace suffering on behalf of users. However in this case C++11 isn't offering enough value in terms of user access, and the argument that Boost.Decimal types in particular would benefit from C++14 constexpr is compelling.

If it has not already been done, it would be worth including the rationale for C++14 in the documentation.

[ckormanyos]

Thank you Vinnie (@vinniefalco) for this very clear, polished and informative clarification. Understood.

Matt (@mborland) do you think this is clear enough now for closing?

[mborland]

Matt (@mborland) do you think this is clear enough now for closing?

I'll link a PR that updates the docs accordingly to close.