Not-Nil-narrowing a field, is it possible?

[ipsquiggle]

I have code that looks like this. The problem is that config.count is not being narrowed so target_count is considered possibly nil.

config = {} ---@type { count: integer|nil }

local target_count
if config.count then
  target_count = config.count
else
  target_count = .... --fancy logic here that returns an integer
end

target_count -- type is `integer|nil`

I can write it this way instead, and get a correctly not-nil type.

config = {} ---@type { count: integer|nil }

local target_count
local c = config.count
if c then
  target_count = c
else
  target_count = .... --fancy logic here that returns an integer
end

target_count -- type is `integer`

I'm guessing this is just a limitation of the type system, so my question is: Is there something else I could do to make this work more smoothly? Copying into a local is really unfortunate, I'd rather not change the structure of the code just to satisfy the type checker, so I might be SOL but can anyone suggest a way of writing this so that target_count is non-nil?

To be clear, the logic in the second branch is not trivial, I'm not just looking for a way to turn this into a oneliner.

Thanks.

[tomlau10]

AFAIK this is indeed the limitation of the current type system, in which a table field cannot be auto type narrowed in if branch. ☹️

If you are unwilling to change the code structure

• maybe you can use a @cast on target_count ?
  https://luals.github.io/wiki/annotations/#cast

local target_count
if config.count then
    target_count = config.count
else
    target_count = ... -- fancy logic here that returns an integer
end
---@cast target_count -nil ### means remove the `nil` type

target_count --> now this will be `integer` only

• or use @as on config.count
  https://luals.github.io/wiki/annotations/#as

local target_count
if config.count then
    target_count = config.count --[[@as integer]]
else
    target_count = ... -- fancy logic here that returns an integer
end

target_count --> now this will be `integer` only

the @cast approach might be cleaner 🤔 since it is on its single line

[ipsquiggle]

Ah, I didn't know about either of these features! I guess I need to dig deeper into the documentation. Thank you very much. 😄

[CppCXY]

I suggest you try emmylua:

[ipsquiggle]

I've seen you around advocating for emmylua, and I notice you're a maintainer on both this project and emmylua rust. Switching over would involve convincing my team and dealing with the cost of change... have you ever written up any kind of summary of why a person would choose one server over the other, and what the compatibility issues or switching costs would be?

I'm interested in this as a solution but swapping out the tooling mid-production is gonna take some consideration 😎

[CppCXY]

We haven't migrated the documentation, but I suggest you give it a try. Most features are optional and can be enabled. Our configuration is almost identical to the one with the same name—we directly read .luarc as the configuration and also have our own configuration file format. Our support for annotations is nearly the same, with more practical annotation extensions. We can directly use most of LuaLS's annotation files. Additionally, we have stricter type calculation and design, so there will be more diagnostic reports for exceptions. For quick migration, you can disable some diagnostics.