RFC: Export Keyword for Values

[bradsharp]

Allow users to export methods and values from their libraries directly through the use of the export keyword.

Rendered View

[aatxe]

Perhaps worth mentioning that the future change that would enable
type _EXT.Point = Point -- note: this doesn't actually work today but one day it should would also likely necessitate this restriction on explicit returning as well, since the way we'd likely be able to make that possible is by giving tables the ability to have (phantom, i.e. non-existent at runtime) types associated with them as a value.

[bradsharp]

To me that implies we need to make this functional (even if it's bad). We can't silently drop the second return, and we can't let it override the returned table. If modules supported multiple returns we might be able to get around this by making sure the export table is always the last value returned (e.g. return <user-defined>, _EXT), not sure how others would feel about this.

[aatxe]

Sorry, maybe I wasn't clear. I think the correct behavior here, as you're suggesting in the RFC, is that we should throw an error on any explicit return in a module with export function or export id, and I also think that even though this may seem a bit odd right now since the restriction is specific to exporting values, it's also a restriction we will have for types if we do the work to enable assigning a type into a "field" (not one that exists at runtime) as you had written in the earlier example.

[alexmccord]

Note that it's not entirely syntactic sugar. There are some subtle but useful runtime semantics we can squeeze out.

local mod = {}

function mod.distance(p1: Point, p2: Point)
  local x, y = p1.X - p2.X, p1.Y - p2.Y
  return math.sqrt(x * x + y * y)
end

If you wanted to call mod.distance somewhere else in this module, it will not get inlined because in theory, mod.distance could have been transmuted to a different function with a different implementation.

With export function distance, it's equivalent to local function distance + exports.distance = distance.

[bradsharp]

This is true, and also worth calling out. There's an additional question here around whether we should expose _EXT to users at all. It might be worthwhile if there are legitimate use-cases with metatables but otherwise we might want to make it innaccessible.

[alexmccord]

Yeah I don't want to expose _EXT. It's trivial for the VM to not expose it too, it already does this with loops which introduces 3 locals you can't even use.

[alexmccord]

I also question the value of adding metatable to the export table. I've never seen anyone want to do this, and if they do they can use return with no exports.

[aatxe]

Yeah, in my mind, the initial goal should be to support the primary way people write modules today well, and other use cases can clearly continue to use explicit return. We can always consider adding additional things (like exposing that internal table as an identifier) in the future if we see sufficient motivation for doing so, but we cannot ever take it away if we add it now.

[bradsharp]

Agree with this so let's keep it locked down and if legitimate use-cases come up we can discuss as part of another RFC.

[alexmccord]

One thing I noticed not mentioned here is how this would work with two mutually dependent exported functions. If you replace export with local in this snippet, it doesn't do what you want it to do.

export function f()
  g()
end

export function g()
  f()
end

[aatxe]

I think my personal expectation here is that this is going to behave the same way as locals, and we can perhaps provide a plain export f export g (though I suspect syntactic ambiguity will be an issue here) to let you export a global.

I would be open to hearing reasons why it should go the other way instead and behave like globals, but I think regardless of the choice, we don't want to introduce a new third semantics here, export should behave like one of them.

[bradsharp]

Agree with @aatxe on this one.
If we want to support the described behavior I think we should look into hoisting but that would be a separate RFC.

[alexmccord]

Given that export probably only makes sense at module level, it stands to reason they should work like globals.

[alexmccord]

Another thing: what happens if you use export in a scope that isn't the module scope?

function set(x)
  export function f() return x end -- ????
  return f
end

-- ????
print(set(5)())
print(set("hello")())

We have this problem already, but it's isolated to the type system currently which is easy to break compatibility, but this is runtime stuff.

function f()
  export type Foo = number
end

[bradsharp]

I've actually been wondering how this should work. My feeling is that we either don't allow it or we make it work exactly how it does in the modules function scope. In other words, using export in any function scope creates a module table and returns it as that functions return value. It would be a weird language quirk so I'm leaning towards "it's not allowed" but maybe that's done through linting and not something we actually enforce.

[alexmccord]

Throw an error

What kind of error? Parse error? Compile-time error?

[aatxe]

I'd imagine compile-time.

[alexmccord]

I thought so too, but wanted this to be specified in the RFC.

Also, note that compile-time errors are not shown to the user at edit time currently, and has a problem of only throwing one compiler error. We'll need a linter to warn on mixed use of export/return.

[bradsharp]

Seems like it should be a parse error similar to

return "Foo"
return "Bar"

[aatxe]

Yeah, I suppose it's not hard to make it a parsing error, you just keep a little bit of state to record if you've already seen an export/return and then whichever you see second can produce an error about it.

[nezuo]

I think this is a great UX improvement! I do have one issue with it:

When you require a module with no return in Roblox, it gives the error: "Module code did not return exactly one value."

Having to specify a return by default and then remove it once you add something you want to export would be a bit annoying. I'm not sure what the right solution would be. Is it possible to change the behavior of modules that don't return anything?

[aatxe]

Having to specify a return by default and then remove it once you add something you want to export would be a bit annoying. I'm not sure what the right solution would be. Is it possible to change the behavior of modules that don't return anything?

I think it would be reasonable to have an implicit return {} if no return statement is present since I think that's more-or-less what this RFC is proposing as the meaning of a module (i.e. it returns a table almost always).

[bradsharp]

Having to specify a return by default and then remove it once you add something you want to export would be a bit annoying. I'm not sure what the right solution would be. Is it possible to change the behavior of modules that don't return anything?

I think it would be reasonable to have an implicit return {} if no return statement is present since I think that's more-or-less what this RFC is proposing as the meaning of a module (i.e. it returns a table almost always).

Not sure I agree with return {} being the default. I think it should be return; since you didn't return or export anything.

[ccuser44]

I very much would like this feature in Luau for many reasons (expecially easier AST analysis and standardization), but because it's a syntax change I don't think it meets the bar to be added as a syntax feature.

[ccuser44]

With further introspection I'm leaning fully on the side of not accepting this RFC. While nice in theory the practical gains of the feature are marginal and (in my opinion) don't justifu the increased lexer/parser complexity.

[jackdotink]

As someone who has written a luau parser in luau, and contributed to other luau parsers, the added parsing complexity is just about 0.

[aatxe]

Having to specify a return by default and then remove it once you add something you want to export would be a bit annoying. I'm not sure what the right solution would be. Is it possible to change the behavior of modules that don't return anything?

I think it would be reasonable to have an implicit return {} if no return statement is present since I think that's more-or-less what this RFC is proposing as the meaning of a module (i.e. it returns a table almost always).

Not sure I agree with return {} being the default. I think it should be return; since you didn't return or export anything.

This is already what the behavior is (leaving nothing on the stack) though, and what's why you get an error saying it has to return exactly one value. Returning nothing is returning zero values! There's a question of whether ModuleScript could potentially just be okay with returning zero values as well, but that is technically out of scope for the RFC itself.

[alexmccord]

There's an opportunity to talk about the possibility of adding re-exports here that I think this misses:

export M = require("./foo")

Which can re-export both types and values.

[ccuser44]

As someone who has written a luau parser in luau, and contributed to other luau parsers, the added parsing complexity is just about 0.

Yeah I don't know why I just said that. Adding the export keyword would only require adding a new lex token type and having it generate a SETTABLE instruction that adds the var to the export table.

My point was is that I don't think I don't think this RFC meets the high bar of usefulness that's required for new syntax features. I was originally for approving this RFC but now due to further introsoection I'm againts the idea.