Operator Overloading is Hard - Meguro.es #26

Operator Overloading is Hard 2023/01/25: Meguro.es #26

Decimal as Primitive or Object ?
Was!! (~ 2023/3)
const items = [{price: 1.25m, count: 5m}, {price: 5.00m, count: 1m}]
const tax = 0.1m
const total = items.reduce((acc, {price, count}) => {
return acc + (price * count)
}, 0m)
const price = total * tax
console.assert(expected === price)

No Operator Overloading 2023/3: 22 March, 2023 Meeting Notes We can have the new literals, that’s probably not too complicated, but I would propose not doing is overloading arithmetic operators. My understanding is this is a very difficult thing for the engines to do. We don’t have a good story about overloading, so in the absence of that story, we won’t do it [for Decimal]. And don’t add new primitives. So these would be new objects, not new primitives. The motivation is to keep implementers happy. Adding primitives can be a costly and invasive change. Jesse Alama - Igalia

• https://github.com/tc39/notes/blob/main/meetings/2023-03/mar-22.md#decimal-stage-1-update

Literal & Methods
2023/7: TC39: July, 2023: Decimal: Open-ended discussion
const items = [{price: "1.25", count: 5}, {price: "5.00", count: 1}]
const tax = "0.1"
const total = items.reduce((acc, {price, count}) => {
return Decimal.add(total, Decimal.multiply(price, count))
}, 0)
const price = Decimal.multiply(total * tax)

• https://docs.google.com/presentation/d/19MaO7On6knlweYZUei-d5VyqANzkKeR8QmC13KATvgs/edit#slide=id.g2589078d1af_0_0

Object & Methods
2023/9: Decimal: Stage 1 Update (September 2023)
const items = [{price: "1.25", count: 5}, {price: "5.00", count: 1}]
const tax = new Decimal("0.1")
const total = items.reduce((acc, {price, count}) => {
const curr = Decimal.multiply(new Decimal(price), count)
return Decimal.add(acc, curr)
}, new Decimal("0"))
const price = Decimal.multiply(total * tax)

• https://docs.google.com/presentation/d/1xOvWslwKi6evMWMYk1PQv9H0IEIhsifHbEBh2BOqHa0/edit#slide=id.g27e5fa817e7_0_15

===

Record & Tuple #{ a: 1 } === #{ a: 1 } #[1, 2] === #[1, 2]

Overhead for Override `===` for tuple Status of value semantics? · Issue #387 · tc39/proposal-record-tuple In some engines the pointer itself encodes that it points to a JS-object or a JS-string. This means that the instructions for === have a fast path ... of the two addresses. If R&T are built re-using most of the existing mechanisms for JS-objects, ..., then this means that whenever two objects are compared with === the instructions now lose that fast path and will need to load/follow the two addresses... This extra load instruction while small on it's own could add observable overhead when used in a hot-path of an application.

• https://github.com/tc39/proposal-record-tuple/issues/387

Record & Tuple are in crisis 😱😱😱

Stay tune on #387 Status of value semantics? · tc39/proposal-record-tuple

• https://github.com/tc39/proposal-record-tuple/issues/387