ES Decimal status
david.hopwood at industrial-designers.co.uk
Tue Sep 23 19:49:58 PDT 2008
Mike Cowlishaw wrote:
>> Waldemar Horwat wrote:
>>> Mike Cowlishaw wrote:
>>>>> There is still a blocking issue that's been discussed a lot but left
>>>>> off the issues here:
>>>>> - Treatment of cohorts in the default conversion of decimal to
>>>>> string. [...]
>>>> I'm still not clear what your objections are -- we can discuss on
>>>> Thursday, but the intent here is that the toString conversion be
>>>> reversible [...]
>>> No; I'm complaining about the bizarre results that toString produces
>>> which are counter to its existing behavior. I don't care how many
>>> extra zeroes division sticks at the end of the number because I should
>>> never see them. This has been hashed out many times and also breaks
>>> things such as arrays if left uncorrected.
>> Agreed. It's fine to have an operation that maps decimal128 values to
>> strings reversibly, but '.toString()' should not be that operation.
> I don't really have an opinion on how the operation should be spelled.
That matters, because .toString() is used implicitly in primitive
operations, unlike other most other methods (.valueOf() aside).
> But it would seem nice, not bizarre, for the default conversion from a decimal
> number to a string in ES to work the same as in Java and in the equivalent
> functions and methods for C, C++, Python, many other languages, and in
> existing decimal packages.
Java, C and C++ do not have implicit conversions that call .toString(),
and in particular they don't call it on the index in an array indexing
More information about the Es-discuss