Current Module name space objects implement only @@toStringTag and @@iterator as own properties. It should also implement @@toPrimitive as a method that unconditionally throws a TypeError exception. Without it, the following can occur:
//"Mod1"
export function toString() {
//arbitrary code with side effects
console.log("called export toString function");
return "Module"
}
//-----------------
// mail module
import * as m1 from "Mod1";
console.log(m1 == "Module); //produces side efects before producing true
Note that any operator that applies ToPrimitive to m1 will call the exported toString function (or an exported valueOf)
I'm wondering about the motivation for this bug. Why is it more important that `m1 == "Module"` have no side effect, than that `m1 + ""` have no side effect? Does the @@toPrimitive definition need to be a primordial, or is it sufficient that a user could define it and it would work? Is it bad that the user could override @@toPrimitive and cause == to have ia side effect on modules?
(In reply to Daniel Ehrenberg from comment #1)
> Does the @@toPrimitive definition need to be a primordial, or is it
> sufficient that a user could define it and it would work? Is it bad that the
> user could override @@toPrimitive and cause == to have ia side effect on
> modules?
Users cannot add or redefine properties on module namespace objects (9.4.6.6, 9.4.6.9, 9.4.6.10).