Will __proto__ be treated as prototype for records?

[tolmasky]

In the following:

const x = #{ __proto__: #{ y: 10 } }

Is the expectation that x.y === 10?

[mheiber]

I don't think Records have a proto. They don't participate in prototype chains.

[ljharb]

Typically every primitive that's dotted or bracketed into creates a boxed object, on which __proto__ is accessed. This proposal contains an entirely new kind of primitive that changes the meaning of . and [], so assuming that's acceptable, I'd assume that .__proto__ and ['__proto__'] can have different meanings, including "normal data properties".

[mheiber]

@ljharb do you think there is a way to achieve all three of the following?

1. not changing the meaning of .
2. dot access for Records
3. deep immutability for Records

(similar questions apply for Tuple)

[ljharb]

@mheiber number 1 in that list would mean that these new types must be objects, not primitives, since dot/bracket access always either throws (nullish), or boxes into an object and returns the resulting property (primitive), or returns the resulting property (object).

[mheiber]

Sounds like there's no way, then. Anything with Object in its prototype chain is mutable, as far as I know.

[ljharb]

It’s not about mutability; it could have a [[Prototype]] of null like Object.create(null) - or it could be a primitive that’s boxed into a Record object who has a prototype of Record.prototype which in turn has a [[Prototype]] of null - but for polyfill and security use cases, Record.prototype wouldn’t be able to be immutable.

[ljharb]

iow i think the “bare member access” feature requires it be a proxy, a normal object, or a brand new kind of thing.

[littledan]

I think we have two alternatives here:

1. Treat #{ __proto__: xyz } as #{ ["__proto__"]: xyz }, i.e., as a data property. It would not set the prototype (presumably, we're talking about the prototype of the result of ToObject).

2. Make it an early error to have #{ __proto__: xyz }, forcing people to instead write #{ ["__proto__"]: xyz }. This would also have no effect on the prototype.

I can't make of my mind which one of these I like better.

[littledan]

Does anyone have any thoughts on 1 vs 2 of #46 (comment) ? I guess I'm leaning towards 2. (I hope this is relatively easy thing to nail down; it's a bit of an edge case.)

[andre-matulionis-ifood]

I personally think it should be consistent, so 1 would be appropriate. Forcing it to set it as a computed property could confuse more than the alternative

I consider __proto__ as a special property, but still a property. The alternative 2 would set a new precedent, one that __proto__ is more than a property, since it has this special setting rule.

Anyway, this use case never comes up, so I don't consider this a huge deal.

[littledan]

@andre-matulionis-ifood I agree that consistency should be the main goal here. But I'm confused; isn't __proto__ already a special property? If you have it in an object literal, it already does weird things.

[andre-matulionis-ifood]

I meant to focus on the "property" aspect. @ljharb put it best:

I'd assume that .__proto__ and ['__proto__'] can have different meanings, including "normal data properties".

AFAIK, no property has different behavior whether it is set as prop: xyz or ['prop']: xyz. My opinion is that it is not acceptable to add this aspect specifically to __proto__.

---

Another alternative is that it would throw a error independently of setting through __proto__: xyz and ['__proto__']: xyz.

[senocular]

No property has different behavior whether it is set as prop: xyz or ['prop']: xyz.

@andre-matulionis-ifood __proto__ does in normal object initializers.

If propKey is the String value "__proto__" and if IsComputedPropertyKey(PropertyName) is false, 
then
   Let isProtoSetter be true.
Else,
   Let isProtoSetter be false.
...
If isProtoSetter is true, then
  If Type(propValue) is either Object or Null, then
    Return object.[[SetPrototypeOf]](propValue).

https://tc39.es/ecma262/#sec-__proto__-property-names-in-object-initializers

So

a = { __proto__: { x: 1 } }
Object.getPrototypeOf(a) === a.__proto__ // true
a.x // 1
b = { ["__proto__"]: { x: 1 } }
Object.getPrototypeOf(b) === b.__proto__ // false
b.x; // undefined

Neither 1 or 2 are necessarily consistent. 1 changes the behavior so this special case is ignored for records while 2 effectively keeps the special case but throws because its not allowed, yet still preserves the ability to set that key using a computed property name.

[ljharb]

That was the thrust of my comment; since __proto__ already works that way in objects, I’d expect it to work identically in Records.