Flow: Don't require naming parameters/keys

[j201]

Having parameter names is nice in concrete functions with specific uses, but for more abstract functions that work over any value of a type, the parameter names are better left out. Having worked in TypeScript for a while, there are often instances where other coders and I will end up using 'placeholder' parameter names that don't tell you much about the parameter but instead just add visual noise.

For example, I have a function in one project to map the values of an object using a function. The type of that is:

<T, U>(obj: { [key: string]: T }, fn: (t: T) => U) => { [key: string]: U }

It would be more convenient and more legible just to have something like this:

<T, U>({ [string]: T }, (T) => U) => { [string]: U }

This would also allow parentheses for single-argument functions to be omitted, but that's less important.

Annotations for optional or rest parameters could be added directly to the type name: (number, string?) => number or (number, ...Array<string>) => number.

For more examples, 'lib/core.js' is full of placeholder parameter names that don't add any information:

• https://github.com/facebook/flow/blob/ac69bc04f8b9fad514c803b04bfff245459c3259/lib/core.js#L19
• https://github.com/facebook/flow/blob/ac69bc04f8b9fad514c803b04bfff245459c3259/lib/core.js#L34-L39
• https://github.com/facebook/flow/blob/ac69bc04f8b9fad514c803b04bfff245459c3259/lib/core.js#L80-L114

[gabelevi]

Oh I totally agree. I would love for all these identifiers to be optional. For function types we punted on it for now since we didn't want to confuse people with what TypeScript does.

Typescript treats the types as optional in function types. So

(number, string) => boolean

is interpreted as

(number: any, string: any) => boolean

I think the names are the parts that should be optional, but if we add that feature then it's another thing that means something different in TypeScript and Flow. Definitely something worth considering though.

[j201]

These kinds of options could be specified in the @flow declaration or the .flowconfig file, similar to how JSHint options are specified. I'm not sure if the Flow team wants to keep them more simple, though.

The idea has popped up to have pluggable parsers, which I think would be great. If that was implemented, the main Flow parser could be more or less TypeScript-compatible while alternate parsers could have different or more configurable behaviour.

I still think that TypeScript's defaulting to parameter names rather than types is worse behaviour here, and that even if Flow gets pluggable parsers, having optional names should be considered for the default parser. It's just a matter of weighing the advantages versus causing TypeScript compatibility issues.

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[Gozala]

I would also very much like names to be optional.

I do understand reservations in relation to typescript syntax, although given that (number, string) => boolean would mean very specific thing user will be either better off :) or get a type error (which also could be an opportunity to explain this difference with typescript). This incompatibly would be far more problematic if things were other way round.

[samwgoldman]

Nobody has mentioned this yet, but there is a benefit to parameter names in annotations—IDE support. Nuclide will show the parameter names in the typing suggest context window, which is a really nice feature.

[TiddoLangerak]

Parameters without name could also require a leading colon, to prevent confusing with the Typescript syntax. I.e. (:number, :number) => boolean.

[unscriptable]

Yes! :+1: for omitting the parameter names. They're totally not necessary and just obfuscate the type information.

[unscriptable]

woot!