(New Solver) 'type:parameters()' not returning function's "name", not evaluating nil correctly, and not displaying assertion errors

[JustBorgar]

As showcased in the post below, i’m currently trying to replace the type of a function’s argument:

@JustBorgar

type function inheritMethods(class: type, object: type): type
	assert(class:is("table"), "Invalid Type: 'Class' needs to be a table.")
	assert(object:is("table"), "Invalid Type: 'Object' needs to be a table.")
	
	--Iterate over the class
	for keyType, valueTypes in class:properties() do
		local valueType = valueTypes.read or valueTypes.write
		local key = keyType:value()
		
		--Look for methods
		if valueType and valueType:is("function") then
			local params = valueType:parameters()
			local head, tail = params.head, params.tail
			
			--Override self
			if head and (head[1] == class or head[1] == object) then
				if head[1] == class then
					head[1] = object
				end
				valueType:setparameters(head, tail)
				
				--Insert to obj
				object:setproperty(keyType, valueType)
			end
		end
	end
	
	return object
end

After some further testing I came across 3 issues.

First one being that the new solver fails to correctly evalate if a type exists unless you directly compare it with ‘types.singleton(nil)’, as was the case in the prior code:

local valueType = valueTypes.read or valueTypes.write
if valueType and valueType:is("function") then
	--Doesn't work
end

local valueType = assert(valueTypes.read or valueTypes.write, "'valueType' expected.")
if valueType:is("function") then
	--Works
end

local head, tail = params.head, params.tail
if head and (head[1] == class or head[1] == object) then
	--Doesn't work
end

local head, tail = params.head, params.tail
local head = head ~= types.singleton(nil) and head or {}
if head[1] == class or head[1] == object then
	--Works, but 'head[1]' will display a warning
end

This wouldn’t be as much of an issue, if that didn’t cause warnings like in the last example, which leads to issue 2, using assertions doesn’t display a warning in the type function caller when something goes wrong, making it extremely difficult to debug.

Lastly is issue 3, which is that even after dealing with the previous and attempting to replace the type, the names of the arguments are still missing, instead returning an underscore:

local head = head ~= types.singleton(nil) and head or {}
if (head[1] == number) then --Changed types to number for testing purposes
	--if head[1] == types.number then
		--head[1] = head[1]
	--end
	valueType:setparameters(head, tail)
				
	--Insert to obj
	object:setproperty(keyType, valueType)
end

In this example which is taken from the quoted post, 2 tables were passed, table1 (class) having ‘Salutations(Count: number)’, which is added to table2 (object).

The expected result in this case would be for ‘Salutations(Count: number)’ to be added to object, but instead this results in ‘Salutations(_: number)’, which is not what I’d expect when manipulating the arguments in a function.

Expected behavior

• I expect conditionals to evaluate if a type is nil without explicitly comparing them to a nil singleton (and if not possible i’d expect warnings to be supressed after comparing the type to the singleton).
• I expect the errors in my assertions to be displayed as a warning in the line the type function was called so I can debug correctly.
• I expect ‘type:arguments()’ to return the name of the arguments (even if they can’t be manipulated directly, they should still be preserved, and if not, a way to do so should be provided).

A private message is associated with this bug report

[WheretIB]

Hello and thank you for the report!

• I expect conditionals to evaluate if a type is nil without explicitly comparing them to a nil singleton (and if not possible i’d expect warnings to be supressed after comparing the type to the singleton).

This is by design, nil value and a value of type class representing nil type are not equivalent, this is not going to change.

• I expect ‘type:arguments()’ to return the name of the arguments (even if they can’t be manipulated directly, they should still be preserved, and if not, a way to do so should be provided).

This is not a bug, there is no support for argument names.

• I expect the errors in my assertions to be displayed as a warning in the line the type function was called so I can debug correctly.

Please attach full examples of code which doesn’t work as intended.

Given only parts in this topic, a working example cannot be constructed.
I went to the referenced topic, but it also has code spread out over multiple comments with many conflicting examples of the ‘Car’ class that cannot easily be connected together.

[JustBorgar]

@WheretIB

This is not a bug, there is no support for argument names.

That’s a little dissapointing.

I’d understand if ‘type:arguments()’ couldn’t preserve the argument due to limitations, but not being able to get the argument names in any way, even if I have to reconstruct the entire function with ‘types.newfunction()’ really limits the level of inference I can do with the solver.

I really hope this can be supported eventually.

@WheretIB

Please attach full examples of code which doesn’t work as intended.

Given only parts in this topic, a working example cannot be constructed.
I went to the referenced topic, but it also has code spread out over multiple comments with many conflicting examples of the ‘Car’ class that cannot easily be connected together.

Sure, here’s a standalone example for the assertion thing:

--!strict

type function Repro(tbl: type): type
	assert(tbl:is("table"), "'Tbl' expected to be a table.")
	
	return tbl
end

type RepoTest = Repro<"Value">

type function Repro2(tbl: type): type
	if not tbl:is("table") then
		error("'Tbl' expected to be a table.")
	end

	return tbl
end

type RepoTest2 = Repro2<number>

Here I expected a table, passed an invalid value, and got the generic warning ‘type function is uninhabited’ on the line the type function was called.

In order to properly debug a type function, I need to know where errors happen, otherwise I have to blindly guess why the type function doesn’t return the expected value. I figured this was exclusive to assertions given the examples provided by staff never use them, but user defined error messages seem to not display on errors either.

[WheretIB]

@JustBorgar

I really hope this can be supported eventually.

There is a proposal to make names available luau-rfcs/docs/udtf-function-parameter-names.md at udtf-function-parameter-names · itsmath/luau-rfcs · GitHub

@JustBorgar

Here I expected a table, passed an invalid value, and got the generic warning ‘type function is uninhabited’ on the line the type function was called.

Script Analysis will help you.

We do plan to include multiple errors in the mouse hover tooltip.

[WheretIB]

We made an update and Studio will now show multiple errors on hover: