Claude Pache wrote:
> I agree that `constructor(...args){ return super(...args); }` is better (i.e. less surprising) when the super-class's constructor returns an other object than `this`. However, under the current state of the specification, there is at least one exception: the `Object` constructor ignores its `this` value and creates a fresh object, which is unwanted in the theoretical case you define a class extending explicitly `Object`. I guess that this case could be normalised by using a similar mechanism as `Array` and its [[ArrayInitialisationState]] internal slot?

I thought Allen designed things so

   class C {}

differed from

   class C extends Object {}

so as in the first case to avoid (a) super calling Object and making a 
useless newborn; (b) C inheriting class-side properties from Object.

/be

Claude Pache wrote:
> I agree that `constructor(...args){ return super(...args); }` is better (i.e. less surprising) when the super-class's constructor returns an other object than `this`. However, under the current state of the specification, there is at least one exception: the `Object` constructor ignores its `this` value and creates a fresh object, which is unwanted in the theoretical case you define a class extending explicitly `Object`. I guess that this case could be normalised by using a similar mechanism as `Array` and its [[ArrayInitialisationState]] internal slot?

I thought Allen designed things so

```js
class C {}
```

differed from

```js
class C extends Object {}
```

so as in the first case to avoid (a) super calling Object and making a 
useless newborn; (b) C inheriting class-side properties from Object.