Luau Recap: July 2023

Updates Announcements
#22

Are string interpolation optimizations going to be pursued in the near future?

The inherent improvements towards ergonomics/readability that the use of string interpolation carries shouldn’t come at the expense of runtime performance (to the degree at which it currently does).

It’d be much appreciated if we had a handful of table utility functions (these would go a long way), for example, a table.find overload which accepts a predicate function so it can satisfy a broad range of scenarios including ones where the table is not necessarily a continuous array.

Intended on including more than one example; however, less is more + a predicate func overload to table.find probably has the most merit.

5 Likes
#23

more fire updates from the team, love it!

6 Likes
#24

can we get syntactic sugar for oop pls

3 Likes
#25

Just so you know Luau has a folder in which RFCs are placed which outline upcoming/already implemented features

4 Likes
#26

Like MagmaBurnsV said there, if we get a working example showing the issue, we will be able to investigate it.

4 Likes
#27

‘general typechecking performance’ talks about the time it takes Roblox Studio to perform typechecking.

‘Runtime improvements’ that are mentioned do not require type annotations to work.

But in the future we will have runtime optimizations that rely on type annotations.

4 Likes
#28

I’m not aware of any plans to make performance improvements there.
You should share examples that show a large difference in performance (and not just ""..i vs `{i}` please)

table library methods are implemented in C.
A table.find method with a predicate will actually be slower than Luau implementation because of C->Luau->C transitions for each predicate call.
For this reason, table.foreach and table.foreachi are marked as deprecated now, loop is way better for performance.

There is of course an argument for usability, not performance.
For that, you can just write your own module with helper functions and maybe even share it with the community so that other people don’t have to reimplement the same things.

Maybe we will have a better way to share Luau libraries in the future and provide some Roblox-made starter packs as well, but I can’t guarantee that at current point in time.

6 Likes
#29

@WheretIB

local test = {}
test.__index = test

test.value = "hello"

function test.new()
	local self = setmetatable({}, test)
	
	return self
end


function test:GET()
	self.
end



return test

self. still doesn’t auto complete and suggest me “value”

image

I am sad.

I also can’t do this.
image

4 Likes
#30

Great to here that Roblox had released these functions, will be looking forward to helping facilitate my projects.

5 Likes
#31

Bro the thing yall needa add is, if a nil “self” is detected in a function and is element of a table, then it becomes a Table:FunctionName rather then the conventional Table.FunctionName (which doesn’t pass in self automatically)
image

I can’t go into details why this is important to me, but it really will makes things easier to case check both function and self containing functions

4 Likes
#32

In the scope of Roblox, is there any plans to add support for .luaurc files?

In the case that type definitions through .luaurc files were added, this would give immense power to testing libraries and framework plugins (TestEZ, module loaders, etc.)

The way I see it is by making string attributes with the name '_luaurc' on a script or folder affect either the script or folder’s scripts.

There’s an RFC for this.

In the meantime, here’s my method I use to type idiomatic classes:

local Class = {}
Class.__index = Class

Class.Static = "Hello, world!"

type self = {
	Value: number
}

export type Class = typeof(setmetatable({} :: self, Class))

function Class.new()
	local self = setmetatable({} :: self, Class)
	self.Value = 1
	return self
end

function Class.Method(self: Class)
	print(self.Static)
	return self.Value
end
4 Likes
#33

Yes, we now have someone looking into improving string interpolation performance.

5 Likes
#34

This is a bit unrelated, but what about string literals that kind of just “work”? Take the following example:

local objects = {
    Object1 = {["1"] = 1},
    Object2 = {["2"] = 2},
}

local function GetObject(objectName: "Object1" | "Object2")
    return objects[objectName]
end

The dictionary index will not be automatically inferred, which is an issue in larger codebases that I have experienced numerous times. I wouldn’t see this being too hard to implement either.

3 Likes
#35

Will we ever be able to force unwrap in LuaU? I feel like this is the most needed feature so we don’t have yellow lines bothering us.

2 Likes
#36

I can’t wait for that. Will be sure to correctly type all of my code for best perf. improvements possible!

2 Likes
#37

We really should be able to make type checking that functions like FindFirstChild can do. A string argument that indexes an instance, currently doesn’t have type checking.

local function Test(x: string)
    return workspace[x]
end

Test("Part") --> any (should be workspace.Part)

This would allow for more complicated and more useful autocomplete and would improve my development experience a lot.

4 Likes
#38

For some reason, this was already sufficient enough

export type Class = typeof(setmetatable({}, Class))

you don’t even have to export self

however, it doesn’t work in

function Class:Method()
	
	
end

unless you do this

function Class:Method()
	local self: Class = self
	
end
1 Like
#39

There are a lot of things that annoy me and have not been fixed:

function lib.set_properties(properties: {[string]: any}, ...: Instance)
	for _, instance: Instance in {...} do 
		for property, value in properties do
			local success, errormessage = pcall(function()
				instance[property] = value
			end)
			if not success then warn(errormessage) end
		end 
	end

Here I’ve made a pcall function so that the code doesn’t break when trying to set the property of the instance. Property could be any string so it’s unsafe. Sadly the typechecker doesn’t allow this even though I put it into a pcall.

Next up, type refinement for if return statements is nice, but it doesn’t work with continue statements… I use a lot of continue statements and this is absolutely annoying.

People have listed this before but functions like :FindFirstChild return type Instance instead of Instance? which again, stops certain functionality.

Another thing that I dislike is that when I use :: on a variable, the other lines don’t use the new type given by ::, even when the variable doesn’t get changed. SO I have to use :: on EVERY LINE that uses the variable that could be some type or nil. Or I could put an assert above all of those lines, but that’s extra code that should not be required.

And lastly, why do I always have to stop my functions with another return statement if the return type of the function is some type or nil?

function lib.index_of_instance_in_array(array: {any}, instance: Instance): number?
	for i, array_instance: any in ipairs(array) do if array_instance == instance then return i end end
	return 
end

this would error if I got rid of the return keyword at the end of the function. In my opinion this is just code smell and should automatically return nil at the end of the function if the function has a return type other than nothing.

Should I make a bug report out of this?

2 Likes
#40

There are currently no plans for error suppression inside pcall, I don’t remember this being requested before.

For continue and break I hope that we’ll make that improvement, we recently received an open-source contribution that implements that and will be looking at how good it is.

FindFirstChild can technically fail to find a child, that’s why it’s an Instance?.
We talked before about special access operator that allows you to ignore nil to help navigation, but it will not be implemented: RFC: Do not implement non-nil postfix ! operator. by alexmccord · Pull Request #420 · Roblox/luau · GitHub

We do not plan to make return optional at the end of functions returning Type?.
There’s a runtime difference between returning nil and returning nothing.

I’m not sure that all of your complaints work as bug reports, some sound more like feature requests.

3 Likes
#42

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.