@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.
@focasds
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).
Summary
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.