RFC: Support cyclic requires.

[andyfriesen]

Rendered

We augment the require() function, the module interface, and the type checker to allow modules to cyclically require one another in many cases.

[hgoldstein]

Might be better to indicate this is really one step with two alternatives.

[hgoldstein]

Are there any backwards compatibility issues here?

[karl-police]

how would hot-reloading a module affect everything, since it talks about cache

[hgoldstein]

Wording nit: if I didn't know what an SCC was (or forgot because it's been a bit since my graph theory class), I might assume this only meant direct mutually recursive requires, e.g.:

--- A.luau
local B = require('B')
--- B.luau
local A = require('A')

... and not just any set of modules where every one depends on every other via some chain of requires.

[hgoldstein]

Food for thought, I think this would get tricker with a (sketched out) import syntax:

--- A.luau

import ClassBOne from B

export class ClassAOne extends ClassBOne ... end
export class ClassATwo ... end

--- B.luau

import ClassATwo from A

class ClassBOne ... end
class ClassBTwo extends ClassATwo ... end

... if we're considering this a serious drawback, this seems like the real danger.

[alexmccord]

You could also keep them separate, and instead dispatch one constraint solver in the same component, and dispatch the next one if that one is stuck, and so on, until either all of them completes or all of them are stuck.

This would avoid a constraint from module A making its way into some random metavariable's bounds in module B.

[MagmaBurnsV]

The ceremony required to make modules that don't use static exports participate in cycles seems silly to me. As the RFC mentions, cycles are already rare for projects prior to classes, and since classes go hand-in-hand with static exports, I see no sense in adding an escape hatch for this edge case.

Just support cycles only for modules that use static exports. That way you don't even have to worry about if a module returns a different value since it's impossible.

[karl-police]

So, this is GETVARARGS. Now, the thing I know about it, is that it's often used within function bodies.

Doing local var = ... would mean that it's taking 1 element from the var arg alone.

If I do local a,b,c = ... it would take 3 and not more.

What would the design have to change here? Or what would this syntax mean if it is within function bodies?
Or does nothing change about GETVARARGS and it will stay 1 element, it's just to accept the export table

[karl-police]

Will there be a new kind of type?

I know there's modules that do the following

-- now we could require("Main.luau") for the varargs?
--- A.luau
return function (varargs)
   print(varargs.OurEnvironment) -- inheritance from upper module, I guess.
end

but I guess cyclic requires would solve this too, e.g. for Require Tracer?

-- Main.luau
local PortionA = require("A.luau")

local Main = {
  OurEnvironment = {}
}

PortionA(Main)

[VegetationBush]

Wouldn't it be better if a separate keyword was used instead (i.e., requireDeferred, lazyRequire)? This allows require to stay pure instead of throwing new kinds of errors, or worrying about a workaround to capture tuples after returning the cyclic metatable.

A second benefit to this is that it handles the case where A immediately requires B but B does not immediately require A (which I believe is an edge case that wasn't considered in this RFC).