Could we throw TypeError for the (string) `+` operator?

[hax]

Copy from https://github.com/tc39/proposal-deep-path-properties-for-record/issues/15#issuecomment-1013600285

...overloading + for tuple/record is possible, just like how we overload + for bigints. So #[1, 2] + #[3, 4] === #[1,2,3,4], #{a:1} + #{b:2} === #{a:1, b:2} could work. I'm not sure whether such overloading is good or bad, but I guess that we'd better throw TypeError for any + operation when operand is tuple/record for now, so we keep the overloading possibility in the future.

As the playground, currently tuple/record behave like normal array/object in most cases, I think it's good, but it seems keep the behavior of record + record as object + object and give the result "[object Record][object Record]" seems useless.

It's impossible to fix object behavior, but consider tuples/records are new value type, I believe we can at least throw errors for all the operators which object behavior not useful and could have good use in the future, so we can decide it later.

Not sure whether this have been discussed, so I create this issue.

[ljharb]

Any operator that would currently throw with, eg, ({ valueOf() { throw null }), should be able to throw with Records/Tuples if that's desired.

[acutmore]

The current spec text looks like record + record will throw a TypeError: https://tc39.es/proposal-record-tuple/#sec-tonumber

[acutmore]

And object + record would return '[object <stringTag>][object Record]' https://tc39.es/proposal-record-tuple/#sec-immutable-types-record-tostring

[nicolo-ribaudo]

I would be ok with R&T throwing when implicitly converted to a string of it helps future-proofing, similar to how symbols throw.