[New solver] same types cause union

[5uphi]

real world example

local DataStoreService = game:GetService("DataStoreService")
local dataStore = DataStoreService:GetDataStore("Store")

dataStore:UpdateAsync("Key", function(value: any, keyInfo: DataStoreKeyInfo)
	local metadata: {[string]: any}
	
	if keyInfo then
		metadata = keyInfo:GetMetadata()
	else
		metadata = {}
	end
	
	if metadata.Value then
		return value, {}, metadata
	end
	
	return value, {}, metadata
end)

[gege_hello11 (Thegege)]

Try change
local metadata: {[string]: any}
to
local meta: {[string]: any} = keyInfo and keyInfo:GetMetadata()

[5uphi]

does not help

also this does not help

or like this

[MercuryBromine0]

Hello! Yes, this class of issue (seeing silly looking unsimplified types like {} | {} is something we’re tracking. The other issue you note as a real world example might be running into a different issue, in that the new solver still “greedily” tries to infer return types for functions.

[5uphi]

Your right there not related

Now I realise what’s happening
When a function sees the return for first time it now expects the exact same types for the second return

I guess I would need to define the return type of the function like

function Update() : (any, {number}, {[string]: any})

end

I wonder if a function has multiple returns and if we dont define what’s returned if it should just unionise all the returns?

Or if I define metatable as {[string]: any} should the if check really change the type

Its hard to say but the current behaviour is not a bug so I’ll leave it up to you guys to decide how you believe it should behave

Also the first thing I showed with the {} | {} type is a little strange but I guess is also technically not a bug but does complicate the type

Thanks for the response

[MercuryBromine0]

Also the first thing I showed with the {} | {} type is a little strange but I guess is also technically not a bug but does complicate the type

“Bugs” are always fuzzy in software, but in my mind outputting a type too complex to be read easily is a bug, even if it’s correct.

I wonder if a function has multiple returns and if we dont define what’s returned if it should just unionise all the returns?

Something like that! This was impossible (or at least exceptionally difficult) to do in the old solver, but in the new solver it’s much easier to accomplish.