RFC: Do not allow amendments to require by string that break compatibility

[Dekkonot]

Rendered link.

---

This is getting out of hand and I think we need to seriously consider what breaking require semantics actually means for the language. This RFC attempts to prevent breaking it, because doing so means that library authors and tool maintainers need to engage in a dog and pony show to support changes.

[dphblox]

I'd like to speak in a personal capacity, even though I'm associated with Roblox, I don't work on the Luau team.

I appreciate that one of the implicit promises of RFCs is that accepting an RFC means a feature is "stable to implement", and RFCs containing revisions are prone to erode that system.

I also think it is right and good to revise the contents of past RFCs, so long as it is occasional and managed. For example, this is hardly the first time we've had to revise a "stabilised" feature - think as or any of the other various ambiguous-syntax accidents that have happened.

As I mention in #78, I would classify this issue as important enough to the Luau user base as a whole that ambiguities in the spec should rightfully be corrected. Luau is used in a lot of places beyond just the direct community that's formed in the vicinity of homegrown Roblox OSS, and I would like to think the project is humble enough to discount Roblox's importance and respect further-afield use cases with the same prudence and consideration as cases we come across ourselves.

In particular, I appreciate that this isn't actually fundamentally an issue about Roblox's specific implementation of requires, but a broader tension between two ways of thinking about the Luau module system which are at odds with each other. It's likely that embedded Luau consumers will run into these same issues, so I think revision is the right call here.

All of this said, I'm a consumer of Luau myself. I feel the pain of revisions like these. I get it. We should not endeavour to repeat this.

[Dekkonot]

I fully understand that perspective, and I mostly agree with you. Where I disagree is that the ambiguities present in the current system are in fact enough of a problem to justify a breaking revision.

While I'm not super familiar with how Second Life or other engines have implemented Luau, I don't think this is a particularly common problem. It feels very Roblox-centric, perhaps even exclusive to Roblox. After all, in the modern age of programming... Why would you do what Roblox does?

Taking a step back from my position as both a Rojo dev and an Uplift Games syseng, I really do not think that this is a path Luau should go down lightly. I use Luau in personal projects (it runs a bunch of stuff on my home server, and it's embedded in a toy engine). My perspective isn't coming at this just from a guy who has 100 Lune scripts he'll need to fix (though it doesn't help!), it's also coming at this from someone who really doesn't want to deal with the consequences of require breaking whenever.