Brendan Eich (2013-07-23T17:13:44.000Z)
domenic at domenicdenicola.com (2013-07-24T00:20:54.545Z)
Brendan Eich wrote: > I think this goes in the wrong direction. 'new' implies heap > allocation and reference-type semantics. Value objects do not have > either. Previously, from Claude Pache in April: https://mail.mozilla.org/pipermail/es-discuss/2013-April/029750.html --- > The idea is simply to avoid adding footguns for new features, even if we can't remove the existing ones. > Regarding the issue discussed here, let me elaborate: > Until now, `new Primitive`, where `Primitive` is `Number`, `String` or `Boolean` is, in practice, not a problem, because you never need to create a new number, string or boolean that way. (You can use `Primitive` as a function for typecasting, but it is not felt as the same thing as creating a new value.) Things are different with symbols, so the `new Symbol` footgun is practically a new type of footgun. > Note also that `new Date`, `new RegExp`, `new Map`, etc., work as intuitively expected, and, if I have correctly followed the last discussions, `function* gen() { /* ... */}; myIterator = new gen` (meaning: "I want to get a *new* iterator from that generator function") would also work. > I do agree that special-casing should be avoided. Therefore, I think we should make a rule: `new Primitive` should throw for primitive types, except for legacy numbers, booleans and strings (Don't Break The Web) for which it is not a real issue. ---