Woah. O_O
There is only one word to describe something like this.
Dope.
I didn’t even know that anything like this was in the works! Also, if someone else is more familiar with typescript, please tell me he is making a custom class with this line right here?
type Point = {x: number, y: number}
Real OOP would be something…
The main issue with Lua is that it’s impossible for a compiler to know what the majority of your code will do before execution. This is why vanilla 5.1 only does some basic optimizations like simplifying maths, while LuaJIT only optimizes the code in specific instances. A major culprit of this are 100% type unsafe variables, since a parsed value can be a number or a boolean, a reference or a primitive. For example, if val then end will run if val is anything but false or nil.
I can’t wait to try this out 
Type annotations would be awesome for my lil projects, I am 100% on board with this!
Apologies if this has been reported yet, but just received this error.
ok cool and all
but when are we getting compound operators?
its literally in every programming language besides lua, dont even mention that its supposed to be “simple” and not complex, because this post clearly shows that simplicity isnt really relevant anymore.
if you dont know what im talking about, it is operators like ++, --, +=, -=, *=, and /=.
code like this:
local a = 5
local b = 3
a = a + b
print(a)
can be shortened to this:
local a = 5
local b = 3
a += b
print(a)
it just gets more and more useful the longer the two values you are trying to add together are…
super easy
This question has been asked before. There is no intention to add them soon as stated by zeuxcg.
And there is a downside such as conflict with comment syntax.
I don’t think I said that exactly. I don’t think we are going to ever add ++/— because of syntactic ambiguity. As for += et al - we don’t have this planned right now. Because of complexities with metatables if we ever add this, this would just make the code shorter, not faster. But maybe we will decide it’s worthwhile - ergonomics are important and we’re adding continue for this reason. If we ever add += et all these would be statements though unlike in C-derived languages.
I would think that you just dont reassign the variable? I dont use C# or C++ so I have no idea of any other advantages of using constant instead of just not updating the variable
That is the advantage. Other devs or yourself (after not touching that code for a long time) can’t change it by mistake.
Oh, thanks for correcting me!
Could this problematic behavior be avoided in the compilation step? Where the compound operands could become a statement that is of equal value.
Such as a += b being turned into a = a + b and a *= b becoming a = a * b and so on.
Also what do you mean by this? The operands being “Statements”?
The advantage is that you know for sure that the given variable never changes. In Javascript I often see the phrase “Reduce Immutable State” thrown around and so that is done by using the const keyword.
In “curly bracket languages”/C-derived languages, assignments like that can be expressions.
JavaScript example
let i = 0;
let j = i += 3;
j is assigned to i + 3, and i is actually incremented by 3.
// Don't believe me?
console.log(`i is ${i} and j is ${j}`);
With strict mode enabled I get an error with pcall.
Error: Arugument count mismatch. Function takes 2 arguments but you passed 1
This only seems to happen if I don’t return anything inside the function.
We intentionally chose boolean to be consistent with print(type(true))
I’m getting a warning that I shouldn’t be getting:
local t = {}
do
local y = t
y.f = function(x)
return x + 1
end
end
local n = t.f(5)
It says: W000: (8,11) Key 'f' not found in table t
Of course this is a simplified example, but its giving me warnings over a large piece of code due to how I wrote it.
simple just let us program stuff in C++ or C# then ( ͡° ͜ʖ ͡°)
Is there any way that a type can be used across scripts? For example, I have one module that defines a type “Options”:
type Options = {
Delay: number
}
And then in another script I’m using this module and want to create a table specifying the options:
local options : Options = {
Delay = 5
}
But this causes an error because it doesn’t recognize the type “Options”. Other than having the type redefined, is there any other way to reuse the same type across different scripts?
Except you can’t effectively sandbox that stuff. The whole reason roblox uses lua cause it’s a sandbox language. They probably don’t want a snoopy developer poking about somebodies PC on their platform. That just screams legal issues.
Found this mistake
I also have this with os methods.