Why do TypeScript function and index signatures require naming variables?

[pelotom]

TypeScript Version: all versions up to 2.1.4

This is something that's confused me for a long time about TypeScript. Why is it required to name the parameter x in the type expression (x: A) => B? I know it's possible to use typeof with an expression involving the term, but this is a fairly niche use case, so that most of the time the variable goes unused. I understand that for documentation purposes it can be nice to name the function variables in a type signature. I'm fine with that, but far more important to me is knowing the type of the argument. When first learning TypeScript I was very surprised to learn that, while (A) => B is a valid type expression, it takes the A to be the name of the argument, not the type, and assumes you meant the type to be any! Turning on noImplicitAny eliminates the bugs that can result from that confusion, but it also renders the shorthand (A) => B unusable.

Is it too late to reconsider this design decision? Since A => B (without the parens around A) is currently syntactically invalid as a type, it should be completely backwards compatible to support it as a shorthand for (__nameless_variable__: A) => B.

[aluanhaddad]

Yeah, A => B would work except that as soon as you need to introduce a second parameter, you would need to add parentheses and the whole meaning of the type annotation would change. Furthermore if you forgot, or didn't know that, you need to then add names to both parameters, you would have introduced a major problem.

[pelotom]

You're right. (A) => B needs to mean the same thing as A => B, and imo it means the wrong thing right now. I think this is a breaking change worth making.

[gcnew]

To be honest the lack of names is a major drawback of ML style type annotations. Yes it's convinient in a lot of cases but it's a downside in no less. I don't think introducing a breaking change is justified by any means. Maybe syntax such as naked :Type can be added but declarations such as a: a are not much more verbose.

[DanielRosenwasser]

I think it is too late to make this sort of change. Because of the current behavior, interpreting a single identifier as a type would be a breaking change.

I did once suggest making the annotations mandatory for better behavior, but that is also be a breaking change. I thought it was worth making, but as you can see in that thread, the implicit any case is indeed used for legitimate uses. When you don't already have a type declared for your parameters, it is still useful to express intent through names and arity, and people've taken advantage of that.

---

To consider the other side of things, the current syntax has the benefit that it aligns with the syntax for function/method declarations.

I also believe that it helps with documentation. Having used Haskell in the capacity that I have, I will say that omitting parameter names helps doesn't help anybody when they're learning a new library. While there's something to be said about an easier syntax, types being the only form of documentation for people often makes it difficult to understand intent, so requiring a parameter has its benefits.

[stephencelis]

While I understand it being too late to change the existing behavior, this is definitely a new user onboarding experience issue (see referenced issue above), and I'd hope that the compiler could anticipate these gotchas and help the user catch them. As it stands the situation is a bit puzzling to debug.