I believe you should still be able to export values from within do end blocks, as this could allow for neat namespacing with lexical scoping:

do
	local count = 0
	
	export function increment(): number
		count += 1
		return count
	end
end

-- count and increment not visible here

This is what local modules does, if we had some sort of module keyword.

module M is
  local count = 0

  export function increment(): number
    count += 1
    return count
  end
end

export increment = M.increment

Which is equivalent to a closure, modulo (heh) namespacing/qualified paths/etc.

local function makeM(): () -> number
  local count = 0

  return function() -- ignoring the _actual_ exporting machinery as red herring
    count += 1
    return count
  end
end

export increment = makeM()

You could even instantiate it multiple times. Module functors.

module Make(n: number)
  local count = 0
  
  export function next(): number
    count += n
    return count
  end
end

module Counter = Make(1)

export increment = Counter.next

export incrementX = makeM() -- has its own independent `count` state
export incrementY = makeM() -- and its own independent `count` state

Alternative framing: this is not necessarily a const binding.

export foo = 7
print(foo)
foo = 8

After elaboration, all occurrences of foo are a field projection of the export table that you cannot utter in the surface syntax:

local mod = {}
mod.foo = 7
table.freeze(mod)

print(mod.foo)
mod.foo = 8

And since a field projection foo inherits the permissions of the projected-from lvalue mod which is frozen, foo cannot be reassigned. This avoids talking about const bindings and everything is still framed around the pre-existing mechanism of frozen tables.

It doesn't work if we try to desugar several declarations this way:

export a = 2 -- 1
a = 3        -- 2
export b = 4 -- 3

If table.freeze happens before 2, then 3 should rise an error.
If table.freeze happens at the end 2 shouldn't be an error.
It is easer to use const semantic here

Elaboration is not desugaring and is allowed to fail. Consider:

export a = 1
print(a)
export a = 2
print(a)

If we desugar to its const form, the above snippet is valid because const is allowed to shadow. This is effectively the same as your example. You'd need a rule in this case that rejects any export whose name have already been exported. This makes exports inexpressible in terms of const bindings.

I would consider that code snipped valid. It outputs 1 and 2 and exports a as 2.
I understand it can be confusing for corner cases, but I think this approach makes the language more consistent in design choices.
We could prevent this kind of behavior to disallow constant shadowing on the same level(as JS does), allowing it only in nested scopes. I think it is a good idea in general, but it contradicts Lua(u)'s behavior of shadowing rules for locals. So I would like not to do it to stay consistent.
Also, I consider idiomatic to use "local" intuition for explaining Lua(u)'s syntactic sugar.
For example, local function f is traditionally explained as local f + f = function() formula. Desugaring export with const we keep it 'local' in reasoning without bringing global file-level semantic.

This is quite awkward. What is the value of mod.foo after you call mod.increment()?

local foo = 5

export function increment()
	foo += 1
end

export foo -- ???

Currently, mod.foo after calling mod.increment() would always be 5 because it copies the value of foo into the field foo of the exported table. Instinctively, I want it to be 6 because, to me, export foo looks like it exports an alias to the inner foo which is distinct from export foo = foo which copies the value of foo into the read-only symbol foo.

I know that this RFC says export foo is sugar for export foo = foo, but I'm not so sure about that now, it enables a footgun:

local foo = 5

export function increment()
  foo += 1
end

export foo

export function get()
  return foo -- this will always be 5
end

And we can't even have a linter fire a warning on this (doesn't make sense).

A fix is to be isomorphic to something akin to this, using __index to provide aliasing.

local foo = 5

local function increment()
  foo += 1
end

-- this is an empty table because of `for k, v in mod do` which conflicts with aliasing
return table.freeze(setmetatable({}, {
  __index = function(_, k)
    return if k == "foo" then foo
      else if k == "increment" then increment
      else nil
  end,
}))

I agree this approach would be more flexible and beneficial for some code patterns, but in this case we will loose ability to statically reason about exported values during loading. It will impede some potential optimizations for cross module inlining and constant folding. As soon as Luau doesn't allow to control readonlyness with property level granularity we will need to make some compromises here.
User intention can be expressed using getter function or intermediate object.

I mean, an optimization you can do is literally just move some of the exported symbols into the table part for all exported bindings that have not been mutated (or rather, not mutated through functions). From that you have a guarantee that increment always points to the same function object, whereas foo still goes through __index.

The reason why I didn't do that was because of for k, v in mod do would not iterate over foo. But here, let's just do that. The downside is that now pairs(mod)/rawget(mod, "increment") is weird.

local order = {"foo", "increment"} -- sorted by hash, just like hashmaps
return table.freeze(setmetatable({ increment = increment }, {
  __index = function(_, k)
    return if k == "foo" then foo
      else nil
  end,
  __iter = function(self)
    local i = 0
    return function()
      i += 1
      local k = order[i]
      return k, self[k]
    end
  end,
}))

Problem solved, the compiler or VM can still see that increment field exists in the table and did not require __index.

Module systems are complicated for a reason. You can't hand-wave all the issues away in an RFC with 165 lines that barely even talks about edge cases.

I say if you plan on reintroducing assignability through shorthand exports, don't even bother making exported values unassignable in the first place. I'm actually leaning more in the camp of not even supporting shorthand exports because of this issue.

In my personal opinion, exporting should just be pure syntax sugar that maps exactly to returning a plain frozen table. There should be no special metatable mechanics like the proposed aliasing rules in the desugared form.

Yeah, I think just remove the shorthand export. This RFC is proposing CommonJS-esque modules, not anything fancy like ES modules which has live bindings.

Not sure the RFC should show the desugared representation with any constructs that doesn't exist.

I think it is acceptable as soon as dependency on other RFC explicitly stated and const RFC is not rejected yet.
Of course export proposal cannot be land in this form until const proposal is.

Exporting before a binding is initialized is an error.

Agreed.

Supporting hoisted exports or forward declarations is out of scope for this proposal and may be explored in a future RFC.

Disagree. This is not backward compatible to retrofit and as such it is not a decision we can defer until later, and mutually dependent functions are fundamental in nontrivial programs. Pre-existing idiom allows mutual dependencies already, so this RFC is more or less a downgrade in its current form. In short, this is a design choice we have to make now or never, and deferring a backward-incompatible design choice is the same as choosing to never do it.

If we could resolve names in function bodies after parsing the body itself rather than immediately, then we already support mutual dependencies. This is sort of easy from a conceptual point of view: after parsing the module, all occurrences of AstExprGlobal implies a free variable that are yet to be bound. Walk each occurrence and check if an export binder name exists and then rebind that occurrence to the export binder.

export type t<a> =
  | { type: "leaf", value: a }
  | { type: "node", children: {t<a>} }

export function walk_node<a, b>(
  node: t<a>,
  leaf_fn: (a) -> b,
  node_fn: ({b}) -> b
): b
  return if node.type == "leaf"
    then leaf_fn(node.value)
    else node_fn(walk_children(node.children, leaf_fn, node_fn))
end

export function walk_children<a, b>(
  children: {t<a>},
  leaf_fn: (a) -> b,
  node_fn: ({b}) -> b
): {b}
  local result = table.create(#children)
  for _, node in children do
    table.insert(result, walk_node(node, leaf_fn, node_fn))
  end
  return result
end

As you can see, it is not possible to reorder either walk_node or walk_children. Initially, when the AST is produced, the walk_children at line 12 is an AstExprGlobal which is analogous to a free variable in lambda calculus, and during name resolution we find out that we could bind that walk_children to the binder export function walk_children turning it into a bound variable. Voila, you have mutual dependencies.

This approach will require changes in everything else though, since if export function walk_children defines a local named walk_children, then the reference at line 12 must be an AstExprLocal, which lexically occurs before its declaration! There's a bunch of ICEs that will happen and needs to be taken care of. Presumably the bytecode compiler requires more fixes as well if this was added (@vegorov-rbx?).

With that said, I will be contrarian for a minute because there are problems on the other side of this beyond the existing implementation assumptions that needs to be solved if we decided to support mutual dependencies out of the box, because there's a critical caveat to note: we don't want to rebind any AstExprGlobal to any exports before it was declared except those inside of a function body, and the above approach must continue to maintain this invariant, otherwise you'll end up with nasty bugs in the program like this:

print(nasty()) -- nil

local x = 5

export function nasty()
  return x
end

Which is precisely equivalent to JavaScript's hoisting bug:

console.log(nasty()); // undefined

var x = 5; // change to `let` or `const` for TDZ semantics

function nasty() {
  return x;
}

ES6 added let/const as well as TDZ (short for "temporal dead zone") semantics. Note that we can't make this a compile error because of the below snippet which is "technically well-defined" as per the rule I gave earlier, but is still ill-formed because local x = 5 has yet to be executed:

export function hella_nasty()
  return nasty()
end

print(hella_nasty())

local x = 5

export function nasty()
  return x
end

Unfortunately it is not possible to turn this class of bugs into a compile error because the analysis is nontrivial, and, per Rice's theorem, is undecidable in the general case (hence why TDZ was punted onto the runtime), so if we did support mutual dependencies, then we have these choices:

1. TDZ semantics (please, for the love of god, no)
2. Don't allow module-level code to call exported functions
   • Honestly, module-level code should seldom have side-effects anyway, sans entry points. They're a bit like impl blocks in Rust.
   • That would mean removing this: https://github.com/luau-lang/rfcs/pull/42/changes#diff-444355a7a572290ed4e1533ed7a9de5b36d25acde77f1c7e4d3893558bf2801bR116-R126
3. OCaml-style and for explicit grouping of mutual dependencies.

   export function f()
     ... -- g is available here
   end
   and g()
     ... -- f is available here
   end

I don't think we need to introduce hoisting for this purpose.
It brings more harm than convenience.
I would prefer the code snippet above can be expressed with usage of temporary locals.

export type t<a> =
  | { type: "leaf", value: a }
  | { type: "node", children: {t<a>} }

local walk_children: <a, b> (
  children: {t<a>},
  leaf_fn: (a) -> b,
  node_fn: ({b}) -> b
) -> {b}

export function walk_node<a, b>(
  node: t<a>,
  leaf_fn: (a) -> b,
  node_fn: ({b}) -> b
): b
  return if node.type == "leaf"
    then leaf_fn(node.value)
    else node_fn(walk_children(node.children, leaf_fn, node_fn))
end

walk_children = function<a, b>(
  children: {t<a>},
  leaf_fn: (a) -> b,
  node_fn: ({b}) -> b
): {b}
  local result = table.create(#children)
  for _, node in children do
    table.insert(result, walk_node(node, leaf_fn, node_fn))
  end
  return result
end

export walk_children

I also like OCaml style approach. In this case my snippet will be the desugaring of it.