You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 nameT 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!
The text was updated successfully, but these errors were encountered:
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.
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.
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
denotes a function with an argument named
a
of a type namedA
that returns a value of typeB
. If we leave out theA
we have this: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:
Here the spec wants to say that
invert
takes an argument of typeT
and returns an argument of typeT
. But, in TypeScript/Flow the above syntax actually means thatinvert
takes an argument with nameT
but it doesn't say anything about the type of the argument toinvert
. For the above to make more sense for at TypeScript/Flow user we could instead write: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!
The text was updated successfully, but these errors were encountered: