[Wildcard Variables][spec] Can we reuse _ as a non-binding name in function types or record types?

[srawlins]

Today, it is illegal to repeat _ as a name in these spots:

// The name '_' is already defined.
typedef T = void Function(String _, String _);

// The name '_' is already defined.
typedef void F2(_, _);

// The name '_' is already defined.
void f(void g(_, _)) {}

I don't believe function types are addressed in the current spec. Should the code above be legal under the wildcards feature?

As for records, it is already illegal to name a positional record field _, as "record field names can't be private."

typedef R = (String _, String _);

Would this code become legal under the wildcards feature? Such names would maybe not be considered "private" any longer?

@kallentu @munificent

[lrhn]

I'd say yes.

These locations are "documentation names" that have no effect, other than being readable in the source.
I would generally allow such names to be replaced by _, precisely because the name doesn't matter, and _ is a way to say that there is no name.
Even if they don't introduce variables, the function type parameters do represent something that will introduce local variables. For records, the names of personal fields never introduce anything, but the only thing they resemble is pattern bindings, which are local variables.

For new-style function types and records, you can also just omit the name, which means we could also disallow having a _ for the functions (it's already disallowed for records). That's as much of an exception as allowing it to be non-conflicting, so we may as will allow it for functions, and then it feels inconsistent to not allow it for records.

For old-style function types, ... you should switch to new-style, but using _ would make it clearer that it's an omitted name, not a type. If actually a vendor for those, so definitely allow it there.

Generally, any place you can write a name that:

• either doesn't matter,
• or would introduce a local variable or type variable

we allow _, which then doesn't introduce any names into the scope, and therefore cannot conflict with anything, including other _ declarations.
That includes all places where you can use _ today, where it would introduce the name to a scope as a local or type variable, but with this issue, it also covers parameter names of function types and positional field names of record types, as positions where names doesn't matter.

Top-level, static or instance declarations also introduced the name into a named/referable scope, so a _ is binding there.
(Actually could make it non-binding at too-level. It'd be useless, but so it's var _ = e; as a local variable. A private top-level declaration is only available in the lexical scope, since it is not exported.)

Maybe we should make _ non-binding as an import prefix?
It's like a top-level declaration, but it's also only available in the lexical scope. If you want to import a library only for it's extensions, you may want to import it with a prefix, and never need to refer to it, and as _ would work for that.

[kallentu]

I would expect those examples to be allowed.
We can update the spec to include function and record types.

[kallentu]

Closing. Updated the spec addressing these explicitly.