Wrong return type for file:read

Luanalysis v1.2.3

local function file_contains(filename, text)
  local f = assert(io.open(filename, "r"))
  local found = f:read("a"):find(text, 1, true)
  f:close()
  return found
end

What happens?

No such member ‘find’ found on type ‘void’

What were you expecting to happen?

No error message since f:read("a") returns a string.

This is related to https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis/issues/80, where the return type depends on the string value of the first argument as well. Since the type system allows string values as separate types, this one should be solvable with a few overrides though, at least for the most common formats.

[Benjamin-Dobell]

I still need to write tests, but seems as this is being actively discussed. I’m currently looking at typing file:read and io.read as:

5.0-5.1

---@overload fun(): nil | string
---@overload fun(format: "*a"): string
---@overload fun(...: "*n"): (nil | number), (nil | number)...
---@overload fun(...: "*l"): (nil | string), (nil | string)...
---@overload fun(...: number): (nil | string), (nil | string)...
---@vararg "*a" | "*n" | "*l" | number
---@return nil | string | number, (nil | string | number)...

5.2

---@overload fun(): nil | string
---@overload fun(format: "*a"): string
---@overload fun(...: "*n"): (nil | number), (nil | number)...
---@overload fun(...: "*l"): (nil | string), (nil | string)...
---@overload fun(...: "*L"): (nil | string), (nil | string)...
---@overload fun(...: number): (nil | string), (nil | string)...
---@vararg "*a" | "*n" | "*l" | "*L" | number
---@return nil | string | number, (nil | string | number)...

5.3-5.4

---@overload fun(): nil | string
---@overload fun(format: "a" | "*a"): string
---@overload fun(...: "n" | "*n"): (nil | number), (nil | number)...
---@overload fun(...: "l" | "*l"): (nil | string), (nil | string)...
---@overload fun(...: "L" | "*L"): (nil | string), (nil | string)...
---@overload fun(...: number): (nil | string), (nil | string)...
---@vararg "n" | "a" | "l" | "L" | number | "*a" | "*n" | "*l" | "*L"
---@return nil | string | number, (nil | string | number)...

Basically, at present it’s impossible to properly type this function. We’d need some pretty elaborate type transform logic to make it work 100% reliably i.e. the nth output type is dependent on the nth input type.

However, I believe the above should cover off the most common use cases.

[rillig]

Wow, that already looks impressively accurate, given that the specification of file:read would stretch each and every type system beyond its limits. Well, except for human brains, which apparently are even more flexible at accepting exceptional rules. 🙂