# Consistent decimal semantics

Brendan Eich brendan at mozilla.org
Mon Aug 25 16:55:37 PDT 2008

```On Aug 25, 2008, at 4:41 PM, Waldemar Horwat wrote:

> We're going round in circles on a few issues surrounding Decimal.

It seems to me people have reached the conclusion you already did on
===. I'm not sure anyone advocated otherwise (I've missed most 3.1
calls lately, so can't be sure).

>   Some of these have clear resolutions; others have a little wiggle
> room.  Here's my summary:

have a couple of questions.

> - Should decimal values behave as objects (pure library
> implementation) or as primitives?
>
> If they behave as objects, then we'd get into situations such as
> 3m != 3m in some cases and 3m == 3m in other cases.  Also, -0m !=
> 0m would be necessary.  This is clearly unworkable.

What should be the result of (typeof 3m)?

[snip]

> - What should cross-type === do on 5 === 5m?
>
> These objects are of different types, so it should return false.

Confusion: 5 is of "number" type (a primitive type, typeof agrees),
so "These objects" should have been "These values" -- right?

Sam and I, not going in circles (much), agree that typeof 3m should
be "object", and that we add hardwired operator support for such
Decimal objects.

> - How should mixed type arithmetic work in general?
>
> There are a few consistent design alternatives:
>
> 1.  Always disallow it.  For consistency you'd have to disallow ==
> between Number and decimal as well.

This was what Igor Bukanov and I were advocating last week.

> 2.  Allow it, converting to the wider type (Decimal128).  There are
> a couple design choices when doing the conversion:
> 2a.  Convert per the IEEE P754 spec:  5.1 turns into
> 5.099999999999999644728632119949907m.  This is how most programming
> languages operate (C++, Java, Lisp, etc.) when converting among the
> built-in floating point values (float -> double etc.).

opinion:) Better than alternative 1? If so, why?

> 2b.  Convert the Number to a string and then to a Decimal:  5.1
> turns into 5.1m.  As a special case, -0 would turn into -0m.  This
> might work, but I haven't thought through the implications of this
> one.

Interesting idea.

/be
```