Implicitly resolve exported type of same name as the module

[NightrainsRbx]

Rendered

[surfbryce]

Having something to simplify this would be extremely valuable. I used to name these primary types just "Type" so that externally I could do "Module.Type" and avoid the awkwardness of typing "Module.Module", but of course then you lose the naming context if you use this in a function argument for example.

I think another good option is if we include a new token for type exports, like if we have "export default type Name = ...." or anything similar. This makes it so that we don't rely on the file name matching or any other unexpected behavior to have it automatically assume a type.

[NightrainsRbx]

I think another good option is if we include a new token for type exports, like if we have "export default type Name = ...." or anything similar. This makes it so that we don't rely on the file name matching or any other unexpected behavior to have it automatically assume a type.

I think that relying on the variable's name (as the design specifies) would be less prone to unexpected behavior than using the module's name. Still, I don't think it's dangerous to infer the type from the variable's name or the module's name, in the end, anything you change in a module will affect other scripts that depend on it

Your idea is interesting but has the same problems as the alternative design, and my intention with this feature is more like a syntactic sugar.

[Crazyblox]

I raise a few concerns regarding this.

• Luau may become less human-readable if accepted as common practice.
• There could be less incentive for module hierarchies to be well-structured.
• Mental burden when reading unfamiliar code increases, adding friction to familiarising oneself with new code.

If a type is assigned to something and the path doesn't seemingly-originate from a module, I would assume that the current script I am viewing is responsible for that type; I can see this leading to false debug sessions where all that was missing was the path to the module for said type.

If I have 10 modules required by the script that I am reading and they all implicitly refer to export types, I'd lose all surface-level context of what comes from where, and the structural benefit of how all the code is put together wouldn't be so apparent.
Seeing the exact type path is something I believe helps make Luau very readable.

For behaviour where this is 100% required, you have mentioned in your RFC that it can be locally defined, which is an explicit communication from within the code that this type is coming from a specific location, removing ambiguity and ensuring that this behaviour is exposed for others to read and follow, solving the human-readability issue.

As for the issue regarding types having the same name as the module itself, this seems like more of a fundamental design issue from said modules rather than how Luau operates; Unless there's a valid reason that types have to be the exact same name as the module which holds it, Something.Something could easily become Something.Standard, Something.Data or any other appropriate type name.