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

Omit value identifiers in function type declarations #16668

Closed
jasonkuhrt opened this issue Jun 21, 2017 · 5 comments
Closed

Omit value identifiers in function type declarations #16668

jasonkuhrt opened this issue Jun 21, 2017 · 5 comments
Labels
Duplicate An existing issue was already created

Comments

@jasonkuhrt
Copy link

This is a syntactic feature request. I often find the indentation caused by inline types does great harm to signature readability, e.g.:

const fetchFromQueue = (
  queue: SQS,
  settings: Settings,
): Promise<Array<Error | Job>> =>
  // ...

One of the ways Haskell types are well designed is in this regard IMO. In TypeScript, what I've taken to doing is a bit of a workaround like so:

type fetchFromQueue = (x: SQS, z: Settings) => Promise<Array<Error | Job>>
const fetchFromQueue: fetchFromQueue = (queue, settings) =>
  // ...

This helps me but it would be even better if we were not forced to write the value-level identifiersx: and z:, allowing us to simply write:

type fetchFromQueue = (SQS, Settings) => Promise<Array<Error | Job>>
const fetchFromQueue: fetchFromQueue = (queue, settings) =>
@DanielRosenwasser
Copy link
Member

Unfortunately it's not possible at this point because unannotated parameter names implicitly got an any type. Check out the discussion at #13152.

@DanielRosenwasser DanielRosenwasser added the Duplicate An existing issue was already created label Jun 21, 2017
@DanielRosenwasser DanielRosenwasser changed the title Omit value identifiers in type defs Omit value identifiers in function type declarations Jun 21, 2017
@jasonkuhrt
Copy link
Author

@DanielRosenwasser Thanks for pointing me to the existing discussion on this topic! Is it conceivable that this could be resolved in say a future 3.x.x release series or is TS going to the way it is on this point indefinitely?

@mhegazy
Copy link
Contributor

mhegazy commented Aug 17, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed Aug 17, 2017
@jasonkuhrt
Copy link
Author

That's fine I guess... heh. I would appreciate an answer to my last question though (if there is a known answer).

@kitsonk
Copy link
Contributor

kitsonk commented Aug 18, 2017

I doubt there is a known answer. Especially, as noted in the other issue that this is marked a duplicate of, some of the core team felt it was worth taking the hit from a breaking change, but ultimately the change didn't occur. But never say never... The core team has re-evaluated things before.

@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants