No way to type an object with null prototype

[Arnavion]

Currently the base type of all objects in TS seems to be {}, which looks like an empty type but actually has members inherited from the Object object. This leaves no way to express a type with null prototype.

var foo: ??? = Object.create(null);
foo.toString(); // Want a compile error here

I did accidentally discover that it's possible to type a variable as void:

var foo: void = Object.create(null);

This appears to suppress intellisense for members in VS and the playground, and it is assignable to any (Object.keys(foo) compiles), so it would seem to be what I'm looking for. However this still lets foo.toString() compile somehow - I imagine the void type is getting elevated to Object automatically.

Edit: Ryan's workaround to subtype Object and override all its members to void prevents those properties from being called as functions, but as he points out, that doesn't prevent them from being accessed.

var bar = foo.toString; // Want a compiler error here too. Won't get one with Ryan's workaround.

[RyanCavanaugh]

Not sure why 'Bug' label as this is per spec (3.8.1 Apparent Type).

The best workaround would be to create an object called NotAnObject that has the properties of the built-in Object type, and override all its properties:

interface NotAnObject {
    toString: void;
    toLocaleString: void;
    valueOf: void;
    // etc
}

var x: NotAnObject = Object.create(null);

Technically you could then still write things like var n = x.toString, but x.toString() would be an error as desired.

[Arnavion]

Okay, I've added the requirement of not wanting access to the property to compile either :)

Null-prototype objects are only useful in a minor number of cases (maps, etc.) so I suppose there's no pressing reason to fix this.

[mhegazy]

Marking it as a suggestion. this is a supported ES6 pattern that will need to support

[Arnavion]

Seems this has changed in 1.4. If foo is typed as void, foo.toString is now an error. Playground

$ node ./tsc.js ./foo.ts
foo.ts(1,20): error TS2339: Property 'toString' does not exist on type 'void'.

Is this deliberate? Is it going to stay like this and can I use this feature?

[Arnavion]

Pointed out by @fdecampredon on IRC - by changing @RyanCavanaugh 's example to a class and making the members private, one can make accessing the property also an error.

class NullProto {
    private toString: any;
    /* other Object.prototype members */
}

var foo: NullProto = Object.create(null);
var bar = foo.toString; // error - Property 'toString' is private

---

Pointed out by @spion on IRC - this type still has a usable constructor property, so that needs to be eclipsed as well (based on https://gist.github.com/spion/65e1f98b168be67daefe):

class NullProto {
    private "constructor": NullProto;
    private toString: any;
    private toLocaleString: any;
    private valueOf: any;
    private hasOwnProperty: any;
    private isPrototypeOf: any;
    private propertyIsEnumerable: any;
}

[blakeembrey]

@mhegazy This is going to be a lot more useful and important as time goes by. Would it be possible to maybe make null prototypes the default? Any interface expected to have object prototype methods could easily do extends Object, while every other interface can work on existing structural comparisons. Otherwise, I think there needs to be a built-in type for this - it's not possible to create an interface as described in this issue as every other object can not be assigned to it.

[blakeembrey]

For example, we can't even start describing the node 6 headers object. This errors as string is not assignable to void.

interface Void {
  hasOwnProperty: void
}

interface Headers extends Void {
  [header: string]: string
}

Edit: To clarify, using any does not add value here as people could then still do headers.hasOwnProperty(x) and run into runtime issues.

[Arnavion]

@blakeembrey

Would it be possible to maybe make null prototypes the default? Any interface expected to have object prototype methods could easily do extends Object

Well that would violate ES spec, but since ES does allow classes to extend null and get a null prototype, it might be nice to support it for interfaces as well.

interface Headers extends null {
  [header: string]: string
}

(Of course currently this doesn't compile, and TS doesn't treat extends null for classes correctly either.)

[blakeembrey]

@Arnavion Why would that violate ES spec? I was talking about using it in a type position, not a value position.

interface X extends Object {}

I do like extends null more, which would keep TypeScript in sync with JavaScript semantics where object literals extend object by default (comparison to interfaces here) while we have a syntax that allows nulling the prototype properly.