---@generic T
---@param t T
---@return int, T...
local function some_func(t) end
local tmp1, tmp2, tmp3 = some_func("") -- tmp3 is unknown
I found this when trying to define the return of some function as T, T... since it made it complain if not at the end of an array definition (which might be a bug on its own, but I'd need a feature to replace it...)
In my playing with the example, I found that just swapping out the generic T with a static type like string it suddenly can understand all the returns.
I also found that return_overload seems to break slightly differently
---@generic T
---@param t T
---@return_overload int, T...
local function some_func(t) end
local tmp1, tmp2, tmp3, tmp4 = some_func("") -- tmp4 is unknown
No clue why return_overload specifically treats a variadic return like a "and one more"
To be clear, this (and with return_overload) works correctly:
---@generic T
---@param t T
---@return T...
local function some_func(t) end
local tmp1, tmp2, tmp3 = some_func("") -- all are strings
I found this when trying to define the return of some function as
T, T...since it made it complain if not at the end of an array definition (which might be a bug on its own, but I'd need a feature to replace it...)In my playing with the example, I found that just swapping out the generic
Twith a static type likestringit suddenly can understand all the returns.I also found that
return_overloadseems to break slightly differentlyNo clue why
return_overloadspecifically treats a variadic return like a "and one more"To be clear, this (and with
return_overload) works correctly: