"Late definitions" - define members AFTER asserting type

[PhoenixWhitefire]

I'm not sure if this has been suggested already, but I've run into this issue with typechecking where I say that something has a type, but it gives me a warning because the variable doesn't have all it's members upon declaration:

type MyFunType = {
    Something: () -> ()
}

-- It's just an empty table right *now*, I just define it's members *later*.
local ObjectThatDoesSomething: MyFunType = {}
-- The above gives warning: "Table type 'ObjectThatDoesSomething' not compatible with type 'MyFunType'
-- "because the former is missing field 'Something'"

function ObjectThatDoesSomething.Something()
    while true do
    end
end

In the above example, even though I have indeed defined ObjectThatDoesSomething.Something, it still acts like I haven't because when I tell the typechecker ObjectThatDoesSomething is of the type MyFunType, it's just an empty table.

Ideally, it would be able to see ahead in the script to check if I've defined the members afterwards. A workaround would be to define all the members directly in the table, but I don't really like that stylistically:

type MyFunType = {
    Something: () -> ()
}

-- No warnings.
local ObjectThatDoesSomething: MyFunType = {
    Something = function()
        while true do
        end
    end,
}

[JohnnyMorganz]

You can get the behaviour you want using the type assertion operator. Unsure if that is the recommended way to do this though

type MyFunType = {
    Something: () -> ()
}

local ObjectThatDoesSomething = {} :: MyFunType

function ObjectThatDoesSomething.Something()
    while true do
    end
end

[PhoenixWhitefire]

@JohnnyMorganz the issue with that is that I'm "asserting" what the type is and sidestepping the typechecker entirely. Ideally it should be smart enough to figure out that there's no warning to be had instead of me having to force it off, because otherwise there might be a situation where I do forget to define a member because there wasn't a warning.

[AmaranthineCodices]

The way that Luau treats type annotations makes this not workable. A type annotation on a local is a promise that at all points in the program, that local fulfills that type annotation's constraints. This is why Luau is reporting a type error on the initial assignment: because at that point in the program, the local doesn't fulfill the constraints of its annotation. Consider something like this:

type T = { x: string }
local t: T = {} -- no error
if cond() then -- Luau doesn't know if this branch is taken
    print(t.x) -- oh no
end

t.x = "bar"

In order for Luau to prove that this kind of initialization is safe generally, we need to do more robust control flow analysis than we do today, even in the new type solver. We eventually need to do that control flow analysis for other reasons, but it's not something that's likely to come soon. Even when it does arrive, I'm not sure we'll relax this restriction, because of how Luau considers type annotations to be binding promises that hold at all points in the program.

For this kind of initialization, I'd suggest something like this:

type MyFunType = {
    Something: () -> ()
}

local function Something()
    while true do
    end
end

local ObjectThatDoesSomething: MyFunType = {
    Something = Something,
}

Another option would be to construct the table in another local, and then assign to the annotated local once the table is fully constructed:

type MyFunType = {
	Something: () -> ()
}

local obj = {}

function obj.Something()
	while true do
	end
end

local Object: MyFunType = obj