Actually that was changed, it’s determined by the ClassName property. The case of inheritance is handled by having a union of inheriting class names in ClassName + the base class name itself. Works 
.
3 Likes
I know how to make this work out of the box without requiring any forward declarations. I just haven’t gotten to it yet.
6 Likes
Reminds me of TypeScript. Sweet.
Also, any plans to completely making it fully static?? /joke
2 Likes
This looks just like FreePascal!
Soo glad that I learn this programming language in school because everything here seems so familiar!
2 Likes
Is there a current ETA on when this will be released to production?
I’ve been experiencing a 100% reproducible crash with this beta feature enabled.
4 Likes
Works all great for me, infact I made a Vector6 module just for testing (lol).
I have yet another question that I don’t think has been asked yet, will there be support for default parameters?
For example:
function v6.new(x:number=1, y:number=1, z:number=1)
It’d be really helpful, instead of having to do:
if x == nil then x = 1 end
if y == nil then y = 1 end
if z == nil then z = 1 end
7 Likes
It would be nice if there were a per-SourceContainer property that enabled/disabled type checking features. Either a boolean property on scripts (i.e. “UseTypes”) could be used for this, or an Enum for what interpreter version should be used.
If types were always opt-in for scripts, I think this would fix a lot of backwards compatibility issues involving the introduction of new keywords or syntax. Of course, once the type system is released, it’s probably going to be hard to add any more keywords or syntax, so I hope this is well thought out and tested before it gets released.
5 Likes
I was wondering if you guys released, if I could disable it? Because I just want to stick with regular Lua for right now.
1 Like
The typed Lua is only enabled if you enable the new Lua script analysis feature. you need to be a beta member as wellif you’re not already.
See
With tables types, will type return that type?
Can’t test it but something like
-- Example
type Vector1 = { x: number }
local v1 : Vector1 = { x = 5 }
print(type(v1)) --> Vector1 [?]
Also can this be enabled another way, like maybe as a property of scripts, like a new property, StrictModeEnabled, or maybe writing $strict at the top. Those are just ideas at the top of my head. I don’t like the idea of comments compiling.
1 Like
Unless you put --!strict at the top of your script, it will effectively be disabled. The syntax will still work, but you won’t have to put type annotations unless you really want to.
1 Like
I noticed vast performance improvements on join times in studio. this kind of update makes coding easier so you don’t make stupid mistakes.
same change I’ve seen aswell. You was ment to write the variable local ‘may seem quite stupid’. But I guess it’s how the new beta changes now works
It appears as though the type information for WaitForChild doesn’t have the second argument as optional. This be corrected, as it is optional.
2 Likes
Is the beta option for this supposed to be in the beta studio as well as the normal?
This is very cool! However, I’m not sure I like the direction it continues to push Roblox developer tool development. I completely understand and appreciate the changes that have been made to the Lua language in order to better facilitate Roblox specific development. I also think that adding typing to Luau makes sense and continues down that direction. However, I personally still see no benefits to using Luau type checking over Roblox-ts. Luau with types will have no support outside of the Roblox platform and will be completely dependent on the Roblox team for maintenance. I will also still have to use outside tools like Rojo to support Git source control. New development features are always appreciated but it is disappointing when they are proprietary and nonstandard.
Why was the choice made to extend Luau instead of supporting a mature, more wide-spread language?
Regardless of my personal feelings, I think Luau is very cool and I am excited to watch its continued development.
Why wasn’t a different language used? Because Lua 5.1 is compatible with Luau. All current scripts will continue working flawlessly. To add more reasons, Roblox was entirely built around Lua. Changing the language basically means starting from 0 with no games at all. They could have added a new script instance for a new language, but unless it is C++, Roblox would be based on 3 languages.
Forgot to mention that a new API would have to be made for each instance.
2 Likes
Found another interesting warning when playing with generics
Seems to be leaking a memory address for a nonexistent symbol or something; this number changes every time I highlight this code after the script analysis is run
2 Likes
That’s not true. All games that used “as” as a variable or function name will not work with these changes.
I agree that it would be a great deal of work to add support for another language. However, I would imagine it’s also a great deal of work to build language features onto a language. I would expect it to be easier to add an API layer between a language that can be used in the C++ runtime environment than to modify Luau. But, they could have done some investigation that shows otherwise and that could make total sense.
I just want to understand why they decided to modify Luau into a more proprietary solution instead of going with a more common, well-established language. I would also like to know why they chose to make a new method of file history instead of going with Git or another well established, industry tool. I’m excited for the changes they are making, and I think they will have a great impact on the platform, I would just like to understand why they are choosing proprietary solutions over adapting industry standards.
1 Like