Records: Can we start without optional names on positional fields in Record types

[natebosch]

The proposal says

Each field is a type annotation and an optional name which isn't meaningful but is useful for documentation purposes.

Can we consider starting without this as an option? I'd like there to be fewer choices for authors to make (we already see authors have to think about this in Function types, and make inconsistent decisions). I'd also like to avoid misleading syntax where it looks like there is meaning where there is none. A comment in the same location would provide the same value, without being misleading.

cc @lrhn @munificent @eernstg @jakemac53 @leafpetersen @stereotype441

[lrhn]

As long as a stand-along identifier is interpreted as a type, not a name, I think allowing names should be safe. It matches function types, where we also allow names for positional parameters. You say it's also a problem for function types. Could we give people better guidelines. Maybe: Always give positional parameters a name in a public API (reusable typedef, function parameter type), unless the parameter's meaning is obvious or canonical. (That's where you need the documentation.)

I'm not too worried. I prefer (num x, num y) point to just (num, num) point, it makes it clear what each position means.

[munificent]

Yeah, I'm with Lasse. I agree that giving users a choice to make is a bad thing, but I think being able to document positional fields by name is really valuable and its consistent with function type syntax.

I suppose there is an argument that if the name matters, you should use actual named fields. But, I think the parallel to function signatures is relevant. Positional parameters are quite common in functions. And we surface the name of the parameter in the function's documentation even though it only really means something inside the body of the function itself and not at the API boundary.

I think names for positional record fields are analogous to that.