RFC: Function Parameter Names in User-Defined Type Functions

[itsmath]

Rendered

This RFC proposes a method to add names to function parameters in user-defined type functions.

[gaymeowing]

Shouldn't names be an array of strings?

[itsmath]

Shouldn't names be an array of strings?

Maybe? I was going for consistency with the API for tables (I'd prefer if it just used strings, though)

[alexmccord]

Array of strings might not work. <A, B, C>(p1: A, B, p3: C) -> () is valid. That would correspond to {type.singleton("p1"), nil, type.singleton("p3")} which we all know is bad due to nil showing up in the middle of it.

[itsmath]

Array of strings might not work. <A, B, C>(p1: A, B, p3: C) -> () is valid. That would correspond to {type.singleton("p1"), nil, type.singleton("p3")} which we all know is bad due to nil showing up in the middle of it.

Right. That's why I think it should be more like an unordered map. But should we actually use types.singleton("name") (that's what we use currently in the RFC) or just "name"?

[itsmath]

From what I can tell, in the Luau source code, argument names in function types look like this

struct FunctionType
{
    /* snip */
    std::vector<std::optional<FunctionArgument>> argNames;
    /* snip */
}

To me, this suggests we should go with a type that looks something like one of the following:

-- I'm using [number] here because the table isn't necessarily contiguous,
-- but it could also be written as {string?}?
type ArgumentNames = { [number]: string? }?

or

-- The types should be string singletons
type ArgumentNamesType = { [number]: type? }?

Right now I'm wondering if we could get rid of the optional values in the table to make it a nice contiguous array. Perhaps a zero-length string (or string singleton) could represent missing parameter names instead of nil?

I'm just not sure if it's worth it.

[itsmath]

@deviaze suggested this approach, which I think is a much nicer solution, but it would unfortunately break existing code. If that's acceptable, since user-defined type functions are relatively new, I think this would be a much better option:

type Parameters = {
    { name: string?, type: type }
}

[gaymeowing]

@deviaze suggested this approach, which I think is a much nicer solution, but it would unfortunately break existing code. If that's acceptable, since user-defined type functions are relatively new, I think this would be a much better option:

type Parameters = {
    { name: string?, type: type }
}

Going to nit and say the field for the type shouldn't be named type and should be named value instead, as its the value of the parameter. But this is the nicest approach otherwise.

[itsmath]

Going to nit and say the field for the type shouldn't be named type and should be named value instead, as its the value of the parameter. But this is the nicest approach otherwise.

But it's also the type of the parameter, right? I guess it makes sense to call it value in the type world, but I just find it weird to read it as "the type of the value of the parameter" instead of just "the type of the parameter". I'm fine with either to be honest.

I'm going to be updating the RFC to use this approach since there hasn't been any reviews yet, but if breaking code is unacceptable we can always just revert it.