Handling of particular static properties in TypeScript

[about-code]

I once worked on a TypeScript Pull Request to fix an issue with static properties that match certain standard properties of Function. At the time @sandersn and I aggreed upon throwing errors in TS for the following static class fields due to the reasons outlined in the issue and PR.

member declaration	method declaration	How handled in TS (PR 12065)	Mentioned here in
static prototype = ""	static prototype(){...}	error	#60
static arguments = ""	static arguments(){...}	error
static caller = ""	static caller(){...}	error
static length = ""	static length(){...}	error
static name = ""	static name(){...}	error

This issue is only to ask whether the prior conversations in the TS issue and pull request matter to this proposal. If not just feel free to close it.

Regards.

---

Disclosure: I am not and have not been part of the TypeScript team but write as an independent contributor.

[about-code]

In particular I found this browser behavior at that time.

[littledan]

The browser behavior you report is as I would expect per spec. Do you have any concerns with this design?

[about-code]

No concerns. Not at all. The reason I brought this up was because I could find some discussion around static prototype and this proposal but not about the other properties listed above.

This is purely to ask whether the discussion around TS in 2016 provides anything relevant to you or your specification work around this proposal. Edit: [...] some misleading parts removed

What I can tell is that the browser behavior I saw in 2016 (with respect to "public" static fields) was easy to implement for ES5 based on Object.defineProperty which I consider(ed) a good property for downleveling via transpilers. The same may not hold true for private static fields but that's not something I would raise as a concern towards the standardization comittee, either.

So if tc39 can't find anything relevant about this issue and the linked discussions, feel free to close it.

---

Disclosure: I am not and have not been part of the TypeScript team but write as an independent contributor.

[about-code]

PS: In 2016 I contributed some warnings related to assumptions about Function.name to the MDN docs (today below heading "Function names in classes"). I referred to parts of the ECMAScript2015 spec there which should have affected browser behavior:

Warning: The script interpreter will set the built-in Function.name property only if a function does not have an own property called name (see section 9.2.11 of the ECMAScript2015 Language Specification). However, ES2015 specifies the static keyword such that static methods will be set as OwnProperty of the class constructor function (ECMAScript2015, 14.5.14.21.b + 12.2.6.9).

While the MDN article is only about static name, do you think the behavior towards "built-in" properties in general may be mentioned as an edge case of public static class properties in STATICPUBLIC.md?

[littledan]

@about-code I'd really appreciate any help to improve documentation here, both in the documents in this repo and in notes in the spec. I don't think we'll make normative changes here, and it sounds like you aren't suggesting any.

[about-code]

To confirm: I don't suggest normative changes. I'll soon provide a PR to add some notes to STATICPUBLIC.md as a first step. I would be open to add additional notes to the spec, if desired, but probably need a bit more guidance there or at least need to find out where the best place for those would be. But we may do this as a second step.