Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposed syntax: Omitting angle brackets for generic types with 1 param #34165

Closed
5 tasks done
ssalka opened this issue Oct 13, 2019 · 4 comments
Closed
5 tasks done

Proposed syntax: Omitting angle brackets for generic types with 1 param #34165

ssalka opened this issue Oct 13, 2019 · 4 comments
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript

Comments

@ssalka
Copy link

ssalka commented Oct 13, 2019

Search Terms

  • implicit bracket
  • mapped types generic
  • nested generic
  • syntax brackets
  • syntax omit
  • syntax parentheses

Suggestion

Support a simplified syntax for generic types that have only 1 type parameter. Specifically, Partial<Foo> could also be written as Partial Foo.

Use Cases

  • This feature would allow people to mapped types that are easier to read. As it would be an opt-in syntax (you can still write generic types with <>) there should be no breaking change in code or workflows.
    • Complex/highly-nested types would have the most to gain from this, but it could be done on any generic type, so long as it has only 1 type parameter
  • In certain cases, this feature could also make for more readable error messages involving generic types.
  • This is partially motivated by Scala's support for omitting parentheses in methods with only 1 argument:
    object.method(param)
    // same as
    object method param
    • While I would welcome such a feature for runtime values in TypeScript, here I am only concerned with the equivalent for generic types, the altering of which has no effect on the output JS.
  • There is no drawback to using <> in general, but for sufficiently nested types it can severely affect readability.

Examples

Simple:

With brackets Without
Partial<Foo> Partial Foo
NonNullable<string> NonNullable string
Set<number> Set number

Complex:

With brackets Without
Array<Promise<{}>> Array Promise {}
NonNullable<Partial<Config>[T]> (from #31675) NonNullable Partial<Config>[T] or
NonNullable (Partial Config)[T]
Promise<NonNullable<Partial<Record<string, any>>>>> Promise NonNullable Partial Record<string, any>

The following would be disallowed, namely because they involve types with 2 or more generic parameters:

Record number any
Map string boolean
Pick Foo 'bar'

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.
@dragomirtitian
Copy link
Contributor

I really don't find Promise NonNullable Partial Record<string, any> more readable than the current syntax.

Also adding two syntaxes for the same thing doesn't seem like a good idea. There is not savings in terms of typing, it goes against this is done in other languages that use <> for generics (C#, Java, C++, don't have this space syntax), and the readability claim seems highly debatable to me.

(Just my 2 cents on the matter, happy to be wrong, maybe others will find this new syntax useful)

@Jessidhia
Copy link

I find that this would be more confusing specifically because of the different meaning space-separated identifiers have in other languages, like Scala and Haskell.

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Declined The issue was declined as something which matches the TypeScript vision labels Oct 15, 2019
@RyanCavanaugh
Copy link
Member

Aesthetic preferences aside, doing this would severely impede our ability to add unary prefix type operators (e.g. readonly) in the future. There'd need to be some better upside for the loss of that flexibility.

@ShanonJackson
Copy link

I also find this less readable, i feel like where possible we should standardize a uniform way and not allow (when possible) alternative ways of doing the same thing. I feel like it leads to increased cognitive overhead in reading code, and adds a steeper learning curve to the language.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Declined The issue was declined as something which matches the TypeScript vision Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

5 participants