I have a question, I know this is just a prediction, therefore not perfect, but do you believe, that in this case, such table would pre-allocate memory for the .Changed field?
I know that this is something a lot of code does, so it’s good to know such thing.
function Class.new()
local self = setmetatable({
_bindable = Instance.new("BindableEvent")
}, Class)
self.Changed = self._bindable.Event
return self
end
My “fear” right now is that using setmetatablethis way might deoptimize that behaviour.
Good stuff! Do you guys plan on letting us choose the style of type syntax sometime soon? I really can’t stand pascal syntax and im sure a lot of people can agree with me, I think that C-styled type syntax would be much cleaner
We don’t plan to make major syntactical changes to the language short of when we’re adding new features. We’ve talked about various changes that might be interesting but they inevitably conclude in:
Syntax is a matter of preference
The current syntax is pretty good
Adding disjoint syntax makes the language feel inconsistent; we’ve tried very hard to avoid that and to add new syntax in a way that matches the existing style
Having two different ways to say the same thing syntactically fragments the language which makes learning it more difficult.
The point of the new autocomplete system is precisely to resolve these. They can not be resolved by “fixing” them in the old system because the autocomplete system that works in the editor right now by default is full of special cases and is lacking fundamental features to make it robust. If you have scenarios that you feel are broken wrt autocomplete, please try the new autocomplete beta, and leave feedback on Script Editor: Luau-Powered Autocomplete & Language Features Beta so that we can address it.
We need sg like that but it (was? is?) simply not reliable enough for developing.
I tried it twice.
First time it had so many bugs and missing features that I stopped using it after some minutes. examples: IsA("") gave no suggestions (I think it is solved by now), “elseif” is unknown (not solved) etc.
Some days ago I gave it another chance but I stopped it again, waiting for a more precise one.
In some cases it doesn’t give suggestions for my workspace objects, only for variables.
Keep up developers and beta testers, I hope it will be better soon!
Can you please report the bugs you found in that thread. I know it’s time consuming, but without reports it’s hard for us to improve.
We are tracking some bugs, but we actually don’t have ‘many’ of those on our list.
You say that you’re waiting for a more precise one and it seems that the current autocomplete gives you better suggestions (or maybe the new one didn’t suggest anything at all).
We would be happy to see an example like that.
Great changes, and I’m surprised as usual that my 99% strict-mode codebase is unscathed (i.e. no script analysis warnings) as the type checker is improved.
I do have a question about the type checker… I’ve noticed there’s a caching behavior with script analysis warnings. For example, when I switched to my macbook, I got hundreds of “unknown require” warnings in my team create place even though this issue has been ostensibly fixed, and after I went through and opened up the hundred or so modules that emitted this warning, they all went away and I haven’t seen any since. My guess is that these warnings were cached from a previous time I opened studio on an older version of luau, and the type checker just had to be run once again through all these modules to get rid of these cached warnings from that older version of luau.
Is it possible that this caching behavior would cause some script analysis warnings to not show up when they should, even after a major update to Luau like this? And if so, is there a surefire way I can make sure the script analysis is getting run through all of my hundreds of modules when an update to Luau is released? I don’t want to miss a script analysis warning that only shows up when I finally open up a module that I haven’t touched in centuries.
We don’t cache warnings across different Studio runs. We do cache them in memory, and I know we had issues with script invalidation in TeamCreate - we’ll investigate.
I love all the improvements to performance and type checking (especially performance), but is there an ETA on when we are going to see new features/syntax added to the language? (specifically anything highly requested or nice in this topic) I know type checking, multithreading, and all the other performance enhancements are massive and time-consuming projects, so there is no rush to finish that but it would be nice to have an ETA or confirmation on what or if anything at all is being considered or getting added to the language from that thread.
Note that that thread had hundreds of suggestions and by default you should assume it’s not going to be implemented – we have a point of view on the language evolution and it explicitly doesn’t include adding all features that are being proposed That said, there are going to be more language and library features, some of them from that thread, both in the shorter term and in the longer term. What you’re really asking for, I think, is a roadmap – we don’t have one to share yet but it’s likely that we’ll start sharing our future plans a bit more in the future. Sorry that this is very vague – we have nothing to announce yet.
So I’m not the only one whose noticed that recently?
Also lately, when I type in “Else” and press enter, it’s been auto completing to something else. I forget what exactly - ElapsedTime() or something I think. Not sure if “El” ever auto completed to “Else”, but I certainly never found myself accidentally checking the time before recently, which makes me think it probably did auto-complete correctly at some point.
Just in general I feel like auto-complete has flat out been missing more than hitting lately.
I have a concern about the practicality of the current type system: The fact that the implementation and definition of table types happen in different areas makes types feel flimsy to interact with, especially in projects written outside of studio (we rely on 3rd party type engines to do that, which are not accurate in replicating luau’s linting). Needing to remember to update the type definition every time you change the type implementation, in practice, has made type definitions unreliable because they’re frequently not up to date with the implementation. As a result, we’ve ended up rarely defining table types and instead using annotations as a way of looking up constructors/implementations. Are there plans for the type engine to use constructor functions as a basis for generating locked-table-type definitions?
For example:
function Something.new(): MyType
local t: MyType = {
a: number|Instance = 0, --Not valid syntax
b: string? = "Hi"
}
return t
end
And there can be much cleaner syntax:
type MyType = {
a: number|Instance,
b: string?
}
function Something.new(): MyType
local t = MyType --Allocates a table of the defined type
--Alternatives:
--local t = table.create(MyType)
--local t = new MyType
--local t = new MyType(a = 0, b = "Hi")
return t
end
And something that feels missing is array-like objects with specified layouts. For example:
type ItemID = number
type StackSize = number
type InventorySlot = {
[1]: ItemID, --This syntax is invalid
[2]: StackSize
}
type Inventory = {
InventorySlot
}
This is a common design pattern for making objects easily serializable or easily addressable in communication between modules or client<->server, however it’s just not possible to tell the type system that an array is expected to have a specific type in a specific slot if it is not in all of the slots.
I think really what you’re saying is that writing type-safe code without a type-checker is difficult. This is true and I don’t think this can ever stop being true. We have long-term plans for fixing this, but they are in flux (and simultaneously in progress) so I don’t want to promise anything in particular until we can announce something with confidence.
So I don’t think it’s a syntax problem at all, that feels secondary.
First-class support for different types for indexed elements of tables was discussed; it’s currently not being worked on but we will consider that for the future, as that does come up occasionally.
The problem with your constructor idea is that there’s no defaults that are sensible for many types, so it’s not clear what exactly a dummy constructor like that would do. That said, we have plans to introduce a different way to define and work with objects in the future - we’re really focused as much as possible right now on working with existing data structures developers are used to, but at some point there’s going to be something that’s more ergonomic and performant in type-safe code. We don’t have detailed designs here yet so again nothing concrete to share - yet.
FYI, if you’re using types like that for performance reasons, that’s a bad idea and actually counter-productive in some scenarios. Field access is significantly more optimized in the Luau VM than it is in the vanilla Lua VM, so much so that making your run-time data structure an array of fixed indices rather than a struct with string field names can actually make your code slower rather than faster.
Even for data storage, unless you really need to squeeze every bit of space you can out of a data store key, using named fields is generally a better idea because it’s much easier to debug and migrate between data store structures as your game evolves.
That said, there are going to be more language and library features, some of them from that thread, both in the shorter term and in the longer term. What you’re really asking for, I think, is a roadmap – we don’t have one to share yet but it’s likely that we’ll start sharing our future plans a bit more in the future. Sorry that this is very vague – we have nothing to announce yet.