Add type something = {}

[sdegutis]

🔍 Search Terms

something

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

type something = {}

📃 Motivating Example

function returnTypeofButInAllCaps(a: something) {
  return typeof String(a ?? [].join()).toLowerCase();
  // FIXME: this does not work as expected sometimes
}

💻 Use Cases

1. What do you want to use this for? As a clearer alternative to writing {}
2. What shortcomings exist with current approaches? Nobody really knows what {} means.
3. What workarounds are you using in the meantime? Using {} unwillingly.

[sdegutis]

I'm torn on if it should be something to match any and unknown or Something to match helper types like Exclude orRecord.

[greim]

To add some context, this was sparked by my reddit thread in which I asked how to pronounce {}.

[MartinJohns]

You mistakingly checked this point on the Viability Checklist:

This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types

[sdegutis]

It's meant to be a built in type like any and unknown, not a utility type like Record or Exclude.

[MartinJohns]

That's not what your suggestion suggests. But we already have a built-in type for this. It's {}. Adding anything more will only add to confusion and serves absolutely no purpose.

Reading your use cases I honestly can't tell if this is a joke issue or if it's serious.

[sdegutis]

@MartinJohns I'm always serious. And yes, we do have {} but it's not a built-in named type, it's an empty structural type. And its semantics are utterly confusing. I have literally never known what it allowed, even though I've been writing TypeScript since the year it came out, until @greim mentioned that it's anything other than null | undefined in his reddit post (thanks Greg). The point of this pull request is to make this utterly clear by giving a built-in name to this structural type, one that very clearly indicates what the type represents (undefined and null are the two nothing types, therefore this is something). It may coincidentally be defined next to utility types, but only because I couldn't figure out in the code where any and never are defined; fixing that's on my todo list. In any case, the community deserves to have the something type for its own edification and to demystify TypeScript even more.

[MartinJohns]

I have literally never known what it allowed

It's very explicitly mentioned in the FAQ: any non-null/undefined value. You might want to read it.

The point of this pull request is to make this utterly clear by giving a built-in name to this structural type, one that very clearly indicates what the type represents (undefined and null are the two nothing types, therefore this is something).

But.. it really doesn't make it clear. The name doesn't make it obvious, you need to learn what it means (same with any, unknown and never), so you're back at status quo.

the community deserves to have the something type for its own edification and to demystify TypeScript even more.

😆 I'm out.

[sdegutis]

I didn't even know there was a FAQ until today. Plus a word is generally easier to google than punctuation.

Also it's worth noting that at least one person thumbs-up'd both my comment and my PR, which implies that 50% of the community agrees with me. (50% because you and he both read it and 50% of that sample group agreed with me.) Therefore this PR is backed by the voice of the majority of the collective users of TypeScript.

[sdegutis]

The 3 downvotes that appeared after I said the thing about the thumbs-up were very obviously just misclicks that can be ignored.

[jcalz]

It's meant to be a built in type

But that makes it worse. All the reasoning in https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types applies even more to a built-in type. Indeed, I could at least conceivably exclude a TS library with a utility type definition I don't like. If it's part of the language then I'm stuck. By checking that checkbox you have possibly obeyed the letter of the law but the spirit is violated.

_{This is part two in a series of jcalz rants about the semantics of viability checklist items. Stay tuned and collect the whole set.}

[sdegutis]

Oh hey Joe how's it going? Haven't heard from you in a while. Still answering stack overflow questions? Anyway you're wrong and this type should be built in.

[jcalz]

If you want to merely assert your correctness instead of making an argument to convince me then you should really use the as operator. For example: “Anyway you're wrong and this type should be built in as something”

[sdegutis]

Okay you win, that was too clever 😂