if not x then return end should exclude falsy types after the block

[kirdaaa]

local function foo(x: string?): string
    if not x then
        return "nil"
    end

    return "\"" .. x .. "\""
end

Code like this is correct, after the if statement, x cannot be falsy, but analyzer still warns that concatenation is not allowed:

TypeError: Type 'string?' could not be converted into 'number | string'

[zeux]

Yup, this is a current limitation of refinements - we don't implement control flow analysis so we don't propagate the inverse of the if condition to the code after the if..then..else statement. This is on our roadmap to solve this year - will keep this bug open for now. The current workarounds include either putting the rest of the code in the else block, or redundantly asserting assert(x) after the block.

[LoganDark]

redundantly asserting assert(x) after the block.

I find myself doing this all the time now. Thankfully since assert(true) can be fastcalled, it should be super fast to execute.

[hoontee]

Is this still on the roadmap? Myself and my team are getting this type error a bunch.

[alexmccord]

Yes, it's still on the roadmap. The current focus is on the new type checking architecture, but implementing control flow analysis is very high on my priority queue.

[perkcalamity]

Super happy to see that this is on the road map! I utilize guard clauses quite a lot to reduce nested if blocks. I use the assert(var) workaround for the time being. Love, love, loveee Luau!

[ambergamefam]

Glad this is being addressed.

Issues such as this one (as well as bugs like #533, #830 and #535) are affecting usability for Luau to the point that nobody in my institution wants to adopt Luau or strict mode in any of their code, and I have a hard time arguing against them or recommending that people use types even though I always personally write typesafe/strict code. This also affects engineering decisions made in my company, such as what tooling we use; our engineers then tend to still opt for using outdated tools that undermine the ability to use Luau features / typesafe code at all.
So I just want to plead that fixing bugs with type refinement should be TOP priority.

Thanks for your hard work 🙏

[alexmccord]

I was able to implement a smaller version of control flow analysis to help alleviate this pain point. It'll make it into the next Luau release cycle.