Type narrowing within a function

[catwell]

This example causes a type error:

local function f(t: any)
    if type(t) ~= "table" then return end
    for k, v in pairs(t) do
        assert(k and v)
    end
end

2 errors:
foo.tl:3:22: cannot apply pairs on values of type: <any type>
foo.tl:3:23: argument 1: got <any type>, expected {K : V}

You can obviously fix it like this:

local function f(t: any)
    if type(t) ~= "table" then return end
    for k, v in pairs(t as {any: any}) do
        assert(k and v)
    end
end

However if you use t several times in the function it is a bit annoying to cast several times.

This does not work:

local function f(t: any)
    if type(t) ~= "table" then return end
    t = t as {any: any}
    for k, v in pairs(t) do
        assert(k and v)
    end
end

This does but it shadows the variable:

local function f(t: any)
    if type(t) ~= "table" then return end
    local t = t as {any: any}
    for k, v in pairs(t) do
        assert(k and v)
    end
end

How do you deal with things like this? In this case Teal could infer it automatically from the test, but in general it could be helpful to "persist" a cast.

I have this issue in real Lua code I am converting to Teal and the way I work around it for now is by with a sub-function like this:

local function f_table(t: {any: any})
    for k, v in pairs(t) do
        assert(k and v)
    end
end

local function f(t: any)
    if type(t) ~= "table" then return end
    return f_table(t as {any: any})
end

[hishamhm]

Teal does not do type inference with if type(t)... expressions. You could use is and wrap the loop with if t is {any:any}

[quienn]

This should work too:

local function f(t: any)
    if not t is {any:any} then return end

    for k, v in pairs(t) do
        assert(k and v)
    end
end

[mtdowling]

Would you be open to narrowing based on type assertions, or is this is a design decision to only narrow based on “is”? Or does is do everything narrowing based on type would do, so no need?

[lenscas]

Is does everything that type would do and has the potential to do more if it doesn't already do more. So I'd be surprised if there is an actual need for this.

[hishamhm]

It was a design decision to introduce is for this purpose because then we can impose the restrictions that the implementation currently needs to perform the compile-time narrowing (and also support different macro expansions for where clauses). type is both too powerful, because it can match on arbitrary expressions that our flow inference system cannot suport, and not powerful enough, because it only matches on Lua types and not Teal types.