ES Decimal status

David-Sarah Hopwood 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
operation.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list