I’ve already conceded on point 6 that types are not technically functions, and that I’m making an analogy. I think analogies are in the territory of opinions.

If you really want to argue technical correctness on point 5 then let me try to illustrate more clearly what a type parameter list is. First I’ll cite some sources to clarify terminology.

From the Wikipedia article on Generic programming (emphasis mine):

Generic programming is a style of computer programming in which algorithms are written in terms of data types to-be-specified-later that are then instantiated when needed for specific types provided as parameters.

That sentence cites the book “Programming Languages: An Active Learning Approach” by Kent D. Lee, which uses both the terms “type parameter” and “type argument”.

The Typescript Handbook page on Generics uses the terms “type parameter” and “type argument” many times. Here are some excerpts:

The type of generic functions is just like those of non-generic functions, with the type parameters listed first

Generic classes have a generic type parameter list in angle brackets

(I know we’ve been talking about functions, not classes. But both have type parameter lists, and it’s the same concept in both cases, so I think this line is relevant.)

When we use GenericIdentityFn, we now will also need to specify the corresponding type argument

I think we can clearly establish this terminology as it relates to one of the examples from my article:

function useState<S>(initialState: S): [S, (value: S) => void] { /* ... */ }
//               ╰┬╯
//       This is called a "type parameter"


//       This is called a "type argument"
//       ╭────────┴──────╮
useState<"open" | "closed">("open")

And you can see here how type arguments bind to type parameters in a way that is directly analogous to value arguments binding to value parameters:

function useState<S>(initialState: S): [S, (value: S) => void] { /* ... */ }
//               ╰┬╯ ╰────────┬─╯
//                │           └────────────────────────┐
//                └───────────────────────┐            │
//                               ─────────┴────        │
//        type argument binds to type parameter        │
//        ────────┬────                                │
//                │                             ───────┴───────
//                │     value argument binds to value parameter
//                │     ──────┬───────
//       ╭────────┴──────╮  ╭─┴──╮
useState<"open" | "closed">("open")

Your counterargument that “Generic functions can have the type specified” is just a different way of saying that a type argument binds to a type parameter.

Just in case the issue is with the use of the word “list”, a generic function can have multiple type parameters. Thus, a list. Here is another example from my article that demonstrates a list of type parameters:

//                  Two type parameters make a list
//                   ╭────────────┴─────────────╮           
function getOrDefault<Obj, Key extends keyof Obj>(
  obj: Obj,
  key: Key,
  def: NonNullable<Obj[Key]>
): NonNullable<Obj[Key]> {
  const value = obj[key]
  return value != null ? value : def
}

Note that getOrDefault has a type parameter list, and also has a value parameter list (or simply “paremeter list” if you prefer). Therefore it has two parameter lists.

Is the problem that when I use the words “parameter list”, to you that means specifically what I’ve been calling value parameters? And that’s not the same thing as type parameters? I think I’ve been very clear that I’m talking about two lists with different kinds of parameters. If that’s the issue then please make some allowance for the way I’m using terminology, and for the context in which I’m using it.

Maybe the issue is that functions can be called with only value arguments? Or that non-generic functions don’t have a type parameter list? I think I addressed this in my article. Type arguments are implicit, so they can be omitted from call sites. But the type parameter list exists in the generic function definition either way. A non-generic function doesn’t have a type parameter list - but I think an equally valid interpretation is that it has an empty type parameter list, which is expressed in the language by omitting the angle brackets.

Anyway, there’s no way you can say it isn’t true that some functions have two parameter lists when type parameter lists are a thing, and value parameter lists are a thing, and generic functions have both.

You can say that I’m overgeneralizing by saying that all functions have two parameter lists when actually only generic functions have two parameter lists. But I think you’d have to be pretty pedantic to say that makes my point wrong. I think it would be glossing over a nuance. If this is the point you disagree on then let me know.

Or you can say, as I do, that all functions do have two parameter lists, but for non-generic functions the type parameter list is empty, so we don’t write it. That’s my interpretation - or in other words, my opinion, which is not a matter of fact.