Following this, what the developer really wants is to create a string from a
number. So OUString::fromNumber() seems like the obvious name for it. And it
should take numbers of any kind, as it doesn't really matter, in the common
case "give me this number as a string" is conceptually the same whether the
number is a long or float. So that should be the optimal API for the
functionality.
Now some real-world issues may enter into play, e.g. when the number is
integer, it may be useful to specify the radix, which doesn't make much sense
with floats; valueOf() has a default argument there, so it can be handled the
same way. Another thing, since valueOf() is often used when constructing
strings, OUString::fromNumber() may be considered a bit too long and it may
be acceptable trade-off to shorten it to OUString::number(). Anything less,
such as leaking irrelevant implementation details and forcing the developer
to explicitly specify the underlying type, is settling on sub-optimal API
that moves part of the implementation burden on the user of the library.
So, based on this, the best solution to the problem that I can see is
creating fromNumber() or number() , overloaded for all signed/unsigned
int/long/long long types and all floats because of the lame language
ambiguity. The original valueOf() can be wrapped inside #ifndef
LIBO_INTERNAL_ONLY after LO is moved away from this problematic function to
keep it only for external backwards compatibility, while LO itself will no
longer "have" it. So rather than bitting us in small ways every now and then,
the (possibly smaller in the end, if it wasn't for this discussion) effort is
spent now, and the effort is not that big (all the duplicates can be only 6
lines, 2 for doxygen @overload @since, 4 for code forwarding to the overload
taking the largest type). Win/win. And if this is still not convincing
enough, then I give up.