Support symbol properties on namespaces

[ExE-Boss]

Search Terms

• namespace symbol
• namespace symbol property
• namespace symbol properties

Suggestion

The ability to declare symbol properties on TypeScript namespaces.

Use Cases

See DefinitelyTyped/DefinitelyTyped#42154 (comment).

Examples

// doSomething.d.ts
import { promisify } from "util";

declare function doSomething(
	foo: any,
	onSuccessCallback: (result: string) => void,
	onErrorCallback: (reason: any) => void
);
declare namespace doSomething {
	function [promisify.custom](foo: any): Promise<string>;
}

export = doSomething;

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[DanielRosenwasser]

Seems like this is mostly meant for the .d.ts representations - is that the intent? Because otherwise, you can already add computed properties to functions.

function blah() {

}

blah[Symbol.iterator] = 100;

One problem that @weswigham brought up with this is that assuming you're repurposing let/const/var to export these symbols, it would introduce a parsing ambiguity.

export namespace foo {
  export let [xyz] = 10; // currently parses as a binding pattern
}

[ExE-Boss]

#40594 could probably help with this by allowing the following in namespaces:

declare namespace Reflect {
	const toStringTag: "Reflect";
	export { toStringTag as [Symbol.toStringTag] };
}

---

Seems like this is mostly meant for the .d.ts representations - is that the intent? Because otherwise, you can already add computed properties to functions.

Yes, this is intended for the .d.ts representations, which use namespaces for properties on functions:

// foo.ts
const kSymbol = Symbol('symbol');
function blah() {
	// ...
}

blah.foo = 'foo';
blah[kSymbol] = 100;

// generated foo.d.ts
declare const kSymbol: unique symbol;
declare function blah(): void;
declare namespace blah {
	var foo: string;
}

Playground link

---

// expected foo.d.ts
declare const kSymbol: unique symbol;
declare function blah(): void;
declare namespace blah {
	export var foo: string;
	var _kSymbol: number;
	export { _kSymbol as [kSymbol] };
}

[weswigham]

I don't see how export { toStringTag as [Symbol.toStringTag] }; will ever be allowed in JS (I admit syntactically, the affordance makes sense), considering export bindings are hoisted, but the value of Symbol.toStringTag requires execution to occur to be known. We could allow it only in ambient contexts, but that has the possibility of stepping on whatever tc39 might do to allow symbol-named module members natively. The linked ecma262 thread in #40594 only allows literal strings in those positions.

[ExE-Boss]

I mean only allowing it in TypeScript’s namespace construct.

[weswigham]

We could allow it only in ambient contexts, but that has the possibility of stepping on whatever tc39 might do to allow symbol-named module members natively.

😦

[webstrand]

I believe this limitation prevents us from supplying types like

const exampleKey = Symbol();
globalThis[exampleKey] = 1;

since globalThis is a namespace, not a variable with a type.