Luau Recap: February 2020

[Provalities]

@zeuxcg

You might be interested in records (https://www.youtube.com/watch?v=vScM-nk5Avk)

Definitely. Are records going to come to Luau, or is it already built-in without the $ syntax?

[anon66957764]

@nooneisback

As for && and ||, they would be much better as bitwise operators,

Personally, I prefer & and | for bitwise operations as well.

&& and || are only really used in languages like JavaScript or C, and Lua is not any of those.

[GahyGoddess (DharmaGoddess)]

@zeuxcg

type array = { [number]: T }

I love this, it’s really nice looking. I’ll be able to change how I program alot, and be very efficient with this.

@zeuxcg

type array = { [number]: T }

Same for this.

[MettaurSp]

As far as I know, && and || are commonly used for logical comparisons, not bitwise operations. Lua already has logical comparison operators that handle those tasks, so those two operators would be redundant in that use case. Lua 5.3+, JavaScript, C, C++, and many other languages use & and | for bitwise operations, so I don’t really see any kind of logical basis to bring && and || in for those.

[Elttob (dphfox)]

This might be a bug.

Any idea why this happens?

[sjr04 (uep)]

I guess it’s because :FindFirstChild takes two arguments, but the second one (the boolean) is optional. Or maybe because it’s not used to function calls without parentheses??? Does calling it with the string and false (assuming you don’t need it to be recursive) work?

[ImFarley]

Hi, so I actually came across a point today where I needed to use the “continue” command.

I’m a little confused by it at this time.

Is the command already functional? I’m not using Beta features or anything, but it didn’t throw an error and SEEMS to be working correctly.

[Dekkonot]

@zeuxcg

We now support type intersections ( A & B ) in addition to type unions ( A | B ). Intersections are critical to modeling overloaded functions correctly - while Lua as a language doesn’t support function overloads, we have various APIs that have complex overloaded semantics - one of them that people who tried the beta had problems with was UDim2.new - and it turns out that to correctly specify the type, we had to add support for intersections.

It’s about a month too late to be asking this, but can you briefly explain this more? I’m trying to wrap my head around how type intersections were useful here and I can’t for the life of me do it.

[zeuxcg]

It’s a slightly involved concept, but it will mostly be used in our internal APIs. Still:

When a value is A | B, it means it either matches the type A or B but we don’t know which one. For example, string | number could be a string or a number. A different example is { a: number } | { b: number } - this means we know it’s a table that either has a key a or a key b but we don’t know which one.

When a value is A & B, it means it matches both types A and B. This may seem counterintuitive - how can this be? And indeed, some intersections are non-sensical - no value can be string & number.

However, what about { a: number } & { b : number }? This effectively means that the value has both keys a and b. This is actually nifty in some cases, e.g. Instance & { CFrame: CFrame } says “a type that has all fields that Instance has, and also a CFrame field”. Which might be helpful in cases where we expose two types that have a field with a common name but no common base class.

The most important use for this is modeling overloaded functions internally. A type (number) => string | (string) => string represents a function that can’t be called (as far as our type system is concerned) with a number or a string - because this says “it’s either a function that takes a number, or a function that takes a string” - so if you pass it a string and it actually takes a number, it’s not valid to call it.

However, a type (number) => string & (string) => string says “values of this type are functions that can be called with a number and with a string”.

You’re not really supposed to understand this, but if you really want to hopefully you can now

[Tomarty]

Would it be possible for table types to use number names, { 1: number, 2: string } for example?

Most of my game has been refactored to use arrays to boost performance. Here’s a simple class using this design:

local key_Health = 1
local key_Name = 2

return {
    new = function(health, name)
        return {health, name}
    end,
    Heal = function(self, amount)
        self[key_Health] = self[key_Health] + 1
        print("Healed", self[key_Name])
    end,
    
    -- Other modules use these to access our objects:
    kHealth = key_Health,
    kName = key_Name
}

There’s no “right” way to do classes in Lua. Metatables are an intuitive place to start, but simple types with static methods are always the most performant.

My game’s custom compiler can completely omit the above module from my game if I flag the functions as inline, but by default it will just omit the 2 constant module keys, and collapse the rest of the module table to an array (where new → 1 and Heal → 2) for the smallest memory footprint.

I’m designing a scalable MMO, and if my code uses fewer unique strings, then there’s just more room to store things like encoded item and animation data.

[Dekkonot]

To check my understanding, something like UDim2.new would be typed like (number, number, number, number) => UDim2 & (UDim, UDim) => UDim2, correct? That’s where my confusion was, and if that’s right you’ve cleared it up. Thanks!

[zeuxcg]

Yeah that’s right.

[Tzekailim]

Will luau are able to reduce amount of exploiters?

[codyorr4]

the progress is going so well, glad to see that you all are still working hard on this!

[DataBrain (Amber)]

@zeuxcg

local Foo = require(path.to.module)

Will make it possible to refer to types in that module as Foo.Bar . And, importantly, will actually mean that the Foo table itself has a correct type so that we can typecheck access to that table and use of the functions declared within it.

I know this is a little late, but will there ever be a method to share types between modules without requiring that module at runtime? The more I plan out how I want to use typed lua when it comes out, the more I find it absolutely essential that you can circularly share types between modules.

From what I could tell, type MyModule = typeof(require(path.to.MyModule)) was at one point valid syntax in the type checking beta which in theory allows you to get a module’s type without actually requiring it. Rut is this going to be valid syntax upon release of typed lua, and if so would it cause any performance downsides? For example, is the result of such a typeof() statement memoized, or will the script analysis have to re-infer the type of MyModule every time this statement is used?

For me, it is really important that I be able to import types from other modules without requiring those modules at runtime, and it seems like something that is entirely possible within the language, were it not for the fact that importing types (which should not affect procedures at runtime) requires you to require those types’ source module at runtime.

I would really love some kind of type-only script like a “TypeScript” or “TypeModuleScript” that allows types to be exposed, without affecting anything at runtime other than performance optimizations. If there isn’t a straightforward method of sharing types without requiring at runtime, I’m sure there would be some hacky ways to do so using setfenv to replace the functionality of require, but I’d rather not go down that rabbit hole.

[zeuxcg]

typeof(require(path)) should work and should be efficient.