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.

[Wunder-Wulfe]

I have been looking for an RFC like this recently. I have run into an issue regarding typing for events and event handlers.
Specifically, I want to be able to provide appropriate type hints for them without requiring several definitions.

For example, if I have a variadic event type and wish to add hints to specialize it:

type Event = {read Connect: (...any)->Signal}
type Bindable = {read Fire: (self: Bindable, ...any)->(), read Event: Event}

In the current state of the typing engine, I would need to specialize by doing the following:

type TypedEvent<T...> = Event & {read Connect: (self: TypedEvent<T...>, func: (T...)->())->Signal}
type TypedBindable<T...> = Bindable & {read Fire: (self: TypedBindable<T...>, T...)->(), read Event: TypedEvent<T...>}

This prevents parameter names from properly being integrated into the type hint system

-- midi note event example
MidiNoteBindable: TypedBindable<number, number, boolean> = Bindable.new()
-- the only parameter name available in type hinting will be the (self) from the Fire() and Connect() methods

An alternative implementation of this type would involve the definition of the types for the Connect() function, as follows

type TypedEvent<T> = Event & {read Connect:  (self: TypedEvent<T>, func: T)->Signal}
type TypedBindable<T> = Bindable & {read Fire: insertSelf<T, TypedBindable<T>>, read Event: TypedEvent<T>}
-- or perhaps  alternative definitions if applicable:
-- type TypedBindable<T> = Bindable & {read Fire: (self: TypedBindable<T>, parameters<T>...)->(), read Event: TypedEvent<T>}
-- type TypedBindable<T> = Bindable & {read Fire: mergeFuncs<(self: TypedBindable<T>)->(), T>, read Event: TypedEvent<T>}

MidiNoteBindable: TypedBindable<(note: number, velocity: number, on: boolean)->()> = Bindable.new()
-- in theory: all uses of function will be appropriately typed

Where in this example, insertSelf() is a type function of equivalent code:

-- modify when parameter names become an option
type function insertSelf(func, self)
	local params = func:parameters()
	local head = params.head or {}

	-- place self parameter
	table.insert(head, 1, self)
	-- overwrite parameters
	func:setparameters(head, params.tail)

	return func
end

Such an implementation would be possible if the type checker was able to analyze recursive types more extensively, and if parameter names were available, as this would allow for parameter names to be preserved.