@MagmaBurnsV @focasds Replying kind of generally and informationally here, forgive me for the long post. (Some stuff is also not particularly relevant to the original feature request)
Lua already vaguely has the capability to for this. Ignoring that though it’s definitely useful and beneficial control flow and I wouldn’t really say that it’s particularly confusing. Just because you can’t break out of a loop like this right now doesn’t at all mean it’s the norm, or, well, if it does it doesn’t say a whole lot for/against the feature request, otherwise every feature request that wants to make something impossible possible should be considered bad because it’s technically against the norm.
In lua 5.2 there are even labeled gotos which are a whole step up from this and would allow you to jump to different places in the code. I believe that this was considered on the luau GitHub but I don’t know if there was a conclusion or what it was.
While technical limitations are definitely important to consider when writing a feature request, it’s ultimately up to Roblox. A feature request for something technologically challenging doesn’t necessarily make a bad feature request I don’t think, so it’s probably good to keep that in mind. These kinds of requests are always more “controversial” because people often get very stuck on specifics (like syntax or implementation details) which I think is not really always warranted for some requests.
Your example does show a relatively good way to handle this without labeled breaks I think. The coroutines aren’t necessary for the use case given by the OP, but your last snippet demonstrates that by having an outer function, you can ofc return to break out of all loops in that function, and that’s a clean way to handle this imo, though, I do support the feature request, labeled breaks would definitely be really nice (and really useful for some projects I follow).
Well, this exact thing already exists in the form of
__newindex in entirety, it just has the gimick that if you set the value in the table the metamethod is for it won’t fire anymore because
__newindex fires for new values. So, if you’d like to detect changes to a table you can create a blank table with a metamethod that updates the value of some target table you want to detect changes to. Then you can use that “proxy” table instead of the target one.
FYI though there are only a few cases where I can see this being a good idea. In any case I can envision it’s a lot cleaner to create a function/method to do the reading/writing and fire changed events and all that. A metamethod would only really make the syntax more pleasing but the cost is more overhead and ambiguity, and there aren’t many benefits.
I only use
__newindex like this when I’m dealing with arbitrary or unknown code that isn’t written by a user of my code and isn’t written by me, e.g. I’ve written a few code sandboxing tools which use
__newindex in exactly the way I describe to overwrite what a piece of sandboxed code can do.
If you’re writing code for yourself, or providing an API for an end user, ultimately it makes more sense to do your own read/write API to keep track of changes and detecting table changes in a generalized way would not end up providing a whole lot of benefit.