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

Type signatures potentially confusing #4

Closed
paldepind opened this issue Mar 17, 2018 · 3 comments
Closed

Type signatures potentially confusing #4

paldepind opened this issue Mar 17, 2018 · 3 comments

Comments

@paldepind
Copy link

I like how the types here are specified in a more Flow/TypeScript way. I think that type notation is a better fit for JavaScript and I think it'll be more friendly to a wider range of JavaScript developers.

However, in one aspect the current types can be confusing to TypeScript/Flow users. In both TypeScript and Flow this notation

(a: A) => B

denotes a function with an argument named a of a type named A that returns a value of type B. If we leave out the A we have this:

(a) => B

This denotes a function with an argument named a but where the type is unspecified (the Flow/TypeScript compiler will try to infer it).

Consider this code from the specification:

Group<T> {
  invert: (T) => T
}

Here the spec wants to say that invert takes an argument of type T and returns an argument of type T. But, in TypeScript/Flow the above syntax actually means that invert takes an argument with name T but it doesn't say anything about the type of the argument to invert. For the above to make more sense for at TypeScript/Flow user we could instead write:

Group<T> {
  invert: (t: T) => T
}

I know the above is a bit more verbose, but it makes more sense to TypeScript/Flow users. I understand that the difference between the two doesn't seem huge but when you're very used to reading TypeScript/Flow types the current types looks "off".

Thank you for your consideration!

@rpominov
Copy link
Owner

Flow actually allows to omit argument names in function types, e.g. A => B is valid and equivalent to (a: A) => B. And I, for one, always write it as A => B at work where we use Flow, so I kinda used to it.

I don't have a strong opinion on this one too. It makes sense if it'll make signatures more familiar, but will also add a bit of a noise.

@paldepind
Copy link
Author

I see. I had no idea. I thought Flow was similar to TypeScript in this regard. Then what I wrote above only applies to TypeScript.

If you feel that changing (A) => B to (a: A) => B adds too much noise then an alternative would be to have small note for TypeScript users that explains the difference.

@rpominov
Copy link
Owner

Adding a note seems to me like a right move. Done it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants