In practice, I’m not as concerned with the potential pitfall of confusion between a type annotation and an argument name.

 

I think it may look similar when we’re using lowercase variable placeholders in hypothetical examples, but in practice if someone wrote `(a, b) -> bool` where `a` and `b` are parameter names, they’ll get an UndefinedType error complaining that `a` and `b` aren’t valid types. Even before that, I think it would be somewhat unintuitive for someone decide to specify a callable type, then want to put parameters in without types, and go fetch names for those parameters instead of just using “…”. Or if there’s a mix of typed/Any params, that would mean they’re actively alternating between types and param names. 

 

If we want to support either all-or-nothing named params that seems reasonable to me, ie., what Guido mentioned about either fully shorthand or fully spelled out.

 

• In this form a "bare" name represents an argument name and has the implicit type Any, like it has in function definitions

 

What are your thoughts on erroring on this and mandating an explicit Any if you’re using the full form syntax – so all parameters must both have a name and a type if you aren’t using the shorthand version?