Functions override :: assigned types

[M0N0RAIL_2 (Blockunstar)]

Unexpected Behaviour:

when im doing:

type test = {
	hey: (Text: string)->()
}

local test = {} :: test
function test.hey(text: string)
	print(text)
end

test.hey()

im expecting text to show up as Text
yet this is what happens:

Normally, whenever i was doing that, it would usually correctly show what i enforced, but now it doesnt do anymore

Expected behavior:

Now I get it, maybe it was done intentionally so it could remove inconsistent types across your code but sometimes it may be preferable to manually set different stuff (like me wanted to have PascalCase on the people using the api, but having camelCase internally) especially when i have to merge generics and other stuff which i may sometimes need to merge them out of the assigning function

So i don’t know if that’s intentional or not but i personally find it annoying, and if that’s the case can we have a way to enforce manual types from :: ?

NOTE: This only happens on the beta for the newer type resolver, but still back then i had it activated and it worked

[index_self]

I’m surprised that it behaves differently if you define the function with and without the sugar, considering they historically were represented the same within the AST.

type Table = {Function: (A: string) -> ()}
local MyTable = {} :: Table

MyTable.Function = function(B: string) end
-- MyTable.Function is (A: string) -> ()

function MyTable.Function(B: string) end
-- MyTable.Function is (B: string) -> ()

I would actually argue they should change the second syntax to act like the first one because it enforces tighter type correctness.

MyTable.Function = function(A: number) end
-- Type Error

function MyTable.Function(A: number) end
-- Okay

local function Call(Parameter: Table)
	Parameter.Function("Hello")
end

Call(MyTable)

[Yuria_theWitch]

@index_self

I’m surprised that it behaves differently if you define the function with and without the sugar, considering they historically were represented the same within the AST.

They were never represented the same in the AST. Function definitions are AstStatFunction which is entirely distinct from AstStatAssign with an RValue of AstExprFunction.

@M0N0RAIL_2

Now I get it, maybe it was done intentionally so it could remove inconsistent types across your code but sometimes it may be preferable to manually set different stuff (like me wanted to have PascalCase on the people using the api, but having camelCase internally) especially when i have to merge generics and other stuff which i may sometimes need to merge them out of the assigning function

It was not done intentionally, and this is indeed a bug with bidirectional typing in the New Type Solver. There’s fixes coming that improve bidirectional typing in the 681 release, but we checked and unfortunately this particular issue is not fixed by it alone. We’ll add this issue to our backlog and address it when we’re able to.