* having an implicit narrowing conversion from double to bigint is a bad idea,
it should be explicit (it isn't completely obvious from the doc if that is the case).
It's pretty hard to have some constructor conversions implicit and others explicit. Might be possible with enable_if though. Will investigate.
It's a good comment. You know, a third of the people want it one way, another third want it the other way and the others don't care.
This is why creating generic libraries is hard. mp_number is a generic class that should provide whatever implicit/explicit constructor the backend supports. I expect enable_if to allow to define such interface. I'm not saying I have a complete solution already. In general, I will not provide implicit conversions when there is a lost of information. Whether this is a major feature for your library is something we can discuss.
<snip>
In fact, I believe that Boost.Math already set the bar on this one because when using Boost.Math with an extended precision type (this is possible), all implicit conversions to/from the built-in types are supported.
I have no experience with Boot.Math, but I suspect that there are cases where these implicit conversions are not desired, e.g when information is lost.
I understand.
I believe it would be incorrect to treat interaction with built-in types behave one way in Boost.Math and a different way in a potential Boost.Multiprecision.
This is my opinion. Others will have different opinions.
I suspect that I need to see how Boost.Math works :-) Best, Vicente
As far as I know, when you use Boost.Math with any properly wrapped big-float type, the templates expect seamless interaction between the wrapped floating-point type and all built-in data types such as char, short, int, float, double, etc. Now as far as a potential Boost.Multiprecision is concerned, I would recommend that whatever Boost.Math needs for floating-point types should be satisfied by Boost.Multiprecision. Narrowing conversions of built-in floating-point types and big integers do not arise in Boost.Math (as far as I know). And there have been some comments suggesting to forbid these in Boost.Multiprecision. I suspect we can sort all of this out in the review. But my initial feeling is that we have Boost.Multiprecision in a relatively *boost-compatible* state because we have thousands of tests already based on Boost.Math. We will sort this out in review, I hope. Thanks again, Vicente. Best regards, Chris.