Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit

Subject: Re: [boost] [multiprecision] General/design query about which conversions should be implicit/explicit
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-05-31 08:16:55

2014-05-31 13:56 GMT+02:00 John Maddock <jz.maddock_at_[hidden]>:

> Folks,
>
> I have an open bug report https://svn.boost.org/trac/boost/ticket/10082
> that requests that conversions from floating point to rational
> multiprecision-types be made implicit (currently they're explicit).
>
> Now on the one hand the bug report is correct: these are non-lossy
> conversions, so there's no harm in them being implicit.  However, it still
> sort of feels wrong to me, the only arguments against I can come up with
> are:
>
> 1) An implicit conversion lets you assign values such as 0.1 to a rational
> (which actually leads to 3602879701896397/36028797018963968 not 1/10),
> where as making the conversion explicit at least forces you to use a cast
> (or an explicit construction).
> 2) Floating point values can result in arbitrarily large integer parts to
> the rational, effectively running the machine out of memory. Arguably the
> converting constructor should guard against that, though frankly exactly
> how is less clear :-(
>
> Does anyone else have any strong views or insights into this?
>

I remember when discussing the interface of std::optional on
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!forum/std-proposals
people were against having the conversion from U to optional<T> (where U is
convertible to T) because it incurred a run-time cost not immediately
visible to the guy that used the code:

fun(u); // may last longer than you think

Instead a more verbose/explicit construct was preferred.

Regards,
&rzej