Proposal consider vararg returns as forced optional

[TIMONz1535]

How are you using the lua-language-server?

Visual Studio Code Extension (sumneko.lua)

Which OS are you using?

Windows

What is the issue affecting?

Diagnostics/Syntax Checking

Expected Behaviour

I suggest consider vararg returns as optional (can be nil) because no one guarantees that they will be filled in. The same goes for arguments, despite the fact that their type can also be optional or nilable.

If we return at least something, but we don't know the quantity, then the first argument won't be vararg - any, any ....

Thus after that we do not need to additionally specify that the vararg returns is optional.

---@param a string
function test(a) end

---@param ... string
---@return string ...
function f(...) end
local a, b, c = f() --no warn
local a, b, c = f("1")

test(a) --no warn, expected optinal cannot match

---@param ... string?
---@return string? ...
function f(...) end
local a, b, c = f() --no warn
local a, b, c = f("1")

test(a) --warn optinal cannot match

---@param ... string|nil
---@return string|nil ...
function f(...) end
local a, b, c = f() --no warn
local a, b, c = f("1")

test(a) --warn nil cannot match

Actual Behaviour

Vararg arguments are optional, but vararg returns are not.

Reproduction steps

1. Make vararg return of some existing type.
2. It is guaranteed to be infinite - not optional or nil.

Additional Notes

No response

Log File

No response

[TIMONz1535]

Oh, I found a similar thing with arrays, we can't guarantee that the fetched element is represented, but it's almost false when we iterate through length (but "almost", because it still doesn't guarantee that we'll be able to modify the table).
And when we take the value by key, we usually "probably" know that it exists (or no?).

---@type string[]
local strArray
---@type table<integer, string>
local strArray2
---@type table<integer, string?>
local strArray3
---@type table<integer?, string?>
local strArray4

local a = strArray[100] -- not guaranteed
local a = strArray2[100] -- not guaranteed
local a = strArray3[100] -- ok?
local a = strArray4[100] -- ok?

for i = 1, #strArray do
	local d = strArray[i] -- almost ok
end
for i = 1, #strArray2 do
	local d = strArray2[i] -- almost ok
end
for i = 1, #strArray3 do
	local d = strArray3[i] -- almost wrong
end
for i = 1, #strArray4 do
	local d = strArray4[i] -- almost wrong
end

for i, d in ipairs(strArray) do end -- ok
for i, d in ipairs(strArray2) do end -- ok
for i, d in ipairs(strArray3) do end -- ok
for i, d in ipairs(strArray4) do end -- huh? unknown

for i, d in pairs(strArray) do end -- ok
for i, d in pairs(strArray2) do end -- ok
for i, d in pairs(strArray3) do end -- ok
for i, d in pairs(strArray4) do end -- ok