gmpxx implicit conversion between types

[Marc Glisse]

On Tue, 8 Mar 2011, Torbjorn Granlund wrote:

> Ok, should we allow any implicit conversions between GMP types?  I think
> C's type conversions are actively harmful, but C++ has done some cleanup
> in this area with which I am only vaguely.
>
> When dealing with "heavy" types like these, is it in the C++ spirit to
> allow implicit conversions?  Will we do any good by disallowing them?

I would say that the C++ spirit is to allow "safe" and natural conversions 
to happen implicitly for interoperability purposes. For instance:

void f(std::string);
f("hello"); // a std::string is safely constructed with a copy of "hello"

MyInt operator+(MyInt a,MyInt b);
a+3; // a MyInt is constructed from 3 and added to a


On the other hand, it requires an explicit conversion for unsafe or 
unexpected conversions:

creating an exception from a string (containing the error message), or a 
locale from a string (containing the name of the locale), etc

creating a smart pointer from a regular pointer

build a string from an allocator or a length

(you probably see the pattern, building an object vs converting)


A nice example in C++0X:

std::complex<float> -> std::complex<double> -> std::complex<long double>

conversions are implicit towards the right, and explicit towards the left.


Still in C++0X mode:
int i;
short s{i}; // error, narrowing conversion


>From all these examples, it looks like between mpX and mpY there should be 
an implicit conversion in a direction and an explicit one in the other 
direction. The implicit direction being consistent with the return type of 
mpX+mpY.


Will we do any good?
It could help detect bugs. It lets code overloading a function for 
integers and rationals compile. It gives an automatic way to detect which 
type is "bigger".

-- 
Marc Glisse