Implement a loose "delegate" type for the general representation of functions in Luau

Feature Requests Engine Features
#1

Right now, defining functions as parameters for a method in Luau requires them to have a specific signature. While optimal for type checking and enforcement, this has been mildly irritating for the select cases where a function of any signature can be passed into something.

Right now, I have to do this:

function DoSomething(func: any)
    assert(typeof(func) == "function", "Invalid type for parameter 'func' (Expected function, got " .. typeof(func) .. ")")
end

In this feature proposition, I ask for a new replacement to this behavior:

function DoSomething(func: delegate)
    -- func must be just a function in general. Its signature does not matter.
end

Use cases for this behavior most commonly arise in libraries featuring custom callbacks where the parameters and return types are user defined as they are registered, and where the user is also the one invoking those callbacks with their own input parameters and/or return type(s).

I want to use the term delegate so that issues with using a Lua keyword in certain contexts where it would normally be unusable don’t arise.

7 Likes
#2

Please add this! It is impossible to have code that is consistently annotated. I just don’t annotate any functions parameters that accept functions, since the signature would be misleading even if you read the rest of the function and see “oh hey there is a guard against non-functions”. Generic table can be represented with { [any]: any } but similar cannot apply to functions. This will allow me to consistently annotate all my function parameters.

2 Likes
#3

This is a late bump, but I’ve found a good (enough) temporary solution to this requirement.

type Delegate = (...any) -> (...any)

This can be used to represent functions with any signature, however since it uses a variadic return type, it tends to raise a warning W000: Not all codepaths in this function return nil on any function that implements this type. Naturally, this can be resolved by returning nil (this issue is now fixed). Still, it’s better than using any.

2 Likes
#4

(…any?) could probably be used in the return type but I have not found or seen that warning in any of my uses. I also typically called it Closure or Function.

2 Likes