Hello Alvaro,
>> For instance for "random_gaussian(int, int, double)", it may be called with
>> any combination of 3 int/double arguments, each one must be tested and
>> possibly converted to the target type before calling the actual function.
>> For overloaded operators or functions (arithmetics, abs...) there is also
>> the decision about which operator is called and then what conversions are
>> necessary.
>
> I think we should make this as simple as possible -- in particular I
> don't see a lot of value in overloading here. I'd rather have it throw
> an error and force you to write the double with a ".0" when the given
> value is an integer so that it is parsed as a double, rather than
> accepting ambiguous input. Conversely, if you pass a double to the
> integer options, raise an error.
I agree that the overloading and other stuff is not a decisive and very
useful feature of the patch, but I think that the descendant-typing
two-functions recursive evaluation is a good compromise, as it works
without much ado nor ambiguity, and from my point of view the code stays
quite simple with this approach.
So although the benefit (of having overloaded operators and handling two
types expressions) is indeed in practice quite limited, the cost in the
code is low.
Being more restrictive or strict as you suggest would not remove much
code, and would remove some convenience. Also, removing this feature would
induce inconsistencies: integer arguments would allow general expressions,
but only double constants would be ok for double arguments...
So I would rather keep it as it is.
--
Fabien.