New Enum:GetEnums() and EnumItem.EnumType

Enum:GetEnums() is a new function that returns a list of all Enums. This can be used to enumerate over all Enums. Example:

local eenumCount = 0
for _, enum in pairs(Enum:GetEnums()) do
	if string.sub(tostring(enum), 1, 1):lower() == "e" then
		eenumCount = eenumCount + 1
print("There are " ..eenumCount.. " Enums starting with the letter E!")

Which would print the following:

There are 5 Enums starting with the letter E!

EnumItem.EnumType returns the parent Enum of an EnumItem. This can be useful if you want to check if an EnumItem is of a certain type.

game:GetService("ReplicatedStorage").RemoteFunction.OnServerInvoke = function(player, value)
	if typeof(value) == "EnumItem" and value.EnumType == Enum.HumanoidDisplayDistanceType then
		-- the player passed up the correct value type
		return true

So if we want to go list all EnumItems, we could do something like:

for _,enum in pairs(Enum:GetEnums()) do
	for _,enumItem in pairs(enum:GetEnumItems()) do

instead of parsing the API dump?
(not that that’s done a lot)

1 Like

What a godsend.


Love it. Now we just need a way of making custom enumerators and then I can throw my custom Enum module out of the window


The only thing I don’t like about custom Enums (or at least ones that you could add to the Enum global) is that there is the problem of potential conflicts with ROBLOX-created Enums in the future. Any ideas on how we would solve this?


Just don’t allow developers to overwrite official enums (obviously) and generate an error.
If they use a name that wasn’t taken but is now, then sadly enough their psycic powers broke their code.

Can’t we already create custom-enums sort-of though?

Enum = setmetatable({},{__index=Enum})
Enum.Custom = {A=1,B=2}
print(Enum.Custom.A) --> 1
print(Enum.Shape.Block) --> Enum.Shape.Block (or whatever, I forgot)

(does overwrite roblox ones, but it would only “break” code that wouldn’t even use the roblox ones)


This is what I’m worried about, it seems too prone to failure.

1 Like

I would add some kind of service to the game hierarchy (or some kind of special object) in which you can set your custom enumerators (which would then be added to Enum when you run the file), and whenever you open the game file and you’re overwriting some existing enumerator, it can give a warning about it.

I think a special service/object would make sense because in this way, both the client and server knows about custom enumerators from the moment that they are run, so you can also pass the enumitems through remotes etc and they could still be recognised as such on the other end. (which is hard to do if you’re coding your own custom enumerator script, because you have to run them before any other code, and transferring them between client/server is non-trivial)

Scripts that run on other security levels could just ignore the changes made to the enumerator list.


Custom enums are accessed through a sub-library Enum.Custom, instead of directly through the Enum library.


There’s nothing stopping someone from creating a module in ReplicatedStorage that looks like this:

return {
A = 1;
B = 2;

So much simpler and less error prone than a weird API for custom enums.

1 Like

There’s nothing allowing someone to just use Enum.Custom.A without assigning Enum or getfenv() hax

1 Like

There are billions of potential features we wouldn’t be able to get without using getfenv hax. Just because you can’t normally do it, doesn’t imply that it would be a useful thing to have. Requests for features that are more simply implemented in lua really rustle my jimmies :frowning:


I’m with Tomarty on this, its a lot simpler when you just do something like this… not to mention assigning something as a Enum to the Enum library to use across different scripts without this module method is basically identical (on the surface) to setting a table value in _G… which is just a bad practice. This API would be better practice, but still just as annoying (if you’re like me and find _G annoying)

1 Like

Integrating custom enums directly into the Roblox API isn’t going to work. It has all the same problems as using _G. It isn’t modular, and you wont avoid boilerplate.

Keep your enums next to the functions that need them. If those functions are provided by a module, then have it provide the enums as well.

Think of the Roblox API as being one giant module that has the privilege of being getfenv’d into all of your scripts. It uses its own enums all over its own API, and it provides references to them through the Enum object. It wouldn’t make sense to add custom enums here, because the Roblox API isn’t going to use them anywhere.

At most, there could be a feature that works like your Enum module. It would create custom enum objects that you can use in your scripts however you like. They would have no association with the built-in enums, they wont appear in the Enum global, and the Roblox API would have no real reason to be aware of them. But they’re available for your convenience. I imagine the CoreScript team would find this very useful with the Get/SetCore API.


@Lilly_S Can we temp lock this?
And umm… remove their posts?

1 Like

This topic is temporarily closed due to a large number of community flags.