Brendan Eich (2013-07-23T17:13:44.000Z)
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.

—Claude

"""

/be
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.

---