turn enum into @enum

[Maiori44]

when converting old 2.5 code to 3.0 I noticed I changed all enums to a bunch of @define, which made me realise enum would work better as a preprocessor directive that sets many preprocessor variables

[Markos-Th09]

when converting old 2.5 code to 3.0 I noticed I changed all enums to a bunch of @define, which made me realise enum would work better as a preprocessor directive that sets many preprocessor variables

The current implementation of enums is kinda bad already because it doesn't really have named enums (which I prefer). And also it is would be better to remain a keyword

[Maiori44]

If you mean Rust's those are too complex and don't feel necessary in Clue (since tables)

[Markos-Th09]

If you mean Rust's those are too complex and don't feel necessary in Clue (since tables)

No that. I just mean that the enum should have a name. The variants won't really have any value with them.

enum Something{
     A,
     B
}

[Maiori44]

A name would really only be useful for type checking, which is not yet a thing

[Markos-Th09]

A name would really only be useful for type checking, which is not yet a thing

but we don't really need types to implement it it would just be compiled to a table

[Maiori44]

That is..unnecessary?

[Maiori44]

The point of enums is to define state constants more quickly
But since those states are just constant numbers it would be better to make them a compile time thing

[Markos-Th09]

The point of enums is to define state constants more quickly
But since those states are just constant numbers it would be better to make them a compile time thing

but we still need good lua interoperability

[Maiori44]

What?

[Markos-Th09]

if you were to make a library which should also work in lua the the enum must be easy to use to use in lua

[Maiori44]

I guess that's fair

[Maiori44]

How about just having both enum and @enum?
One compiles to global variables that can be used outside of the Clue code (for libraries) and the other is all compile time?

Edit: ...that pinged somone, oops

[Markos-Th09]

I guess if the difference is clear for everyone it they can satisfy both use cases

[Maiori44]

local enum could error saying to use @enum instead
While global enum will work but give a warning

[Markos-Th09]

local enum could error saying to use @enum instead
While global enum will work but give a warning

no need

[Maiori44]

I mean local enum would be deprecated so it would error anyway

[Markos-Th09]

I mean local enum would be deprecated so it would error anyway

what if somebody wanted to just use a named enum in the local scope?

[Maiori44]

They use @enum

[Markos-Th09]

They use @enum

but @enum is not a named enum, which has some use cases outside of a library

[Maiori44]

I doubt naming enums will be useful..

[Markos-Th09]

I doubt naming enums will be useful..

it still has its uses and I would use it for some things

[Maiori44]

Forgot to reply-
Ill need to reflect on this

[ashifolfi]

I doubt naming enums will be useful..

I use them all the time they are extremely useful

[Maiori44]

You use the name all the time?

[ashifolfi]

You use the name all the time?

Yes I name my enums. Being able to have a single named enum with values of simple names like say FileMode.Read (C# style enum) is very very helpful for code readability and just writing the code in general. Even in my own Lua enum implementation I use a named enum setup.

I see enums as a group of number constants that belong to a single "type" which is the name. Without that name they lose a chunk of their meaning

[ashifolfi]

Enum values are almost always prefixed with a shared name for organization no matter the language so why not just group them under that name automatically with a named enum system. Cutting out the need to manually type that prefix each time.

[Maiori44]

Because Clue does not have types (yet) so the name would not be used

[ashifolfi]

Because Clue does not have types (yet) so the name would not be used

?????? That doesn't mean anything? They should all have the type be used somewhere in calling them? Like C# does Type.Value and my Lua implementation initially used Type_Value. (I have since swapped to C# style)

[ashifolfi]

The point is making them visibly related to each other along with type checking. Not exclusively type checking.

[Maiori44]

How could Clue store a type inside a number?

[ashifolfi]

How could Clue store a type inside a number?

By defining the type as the name of an enum you'd tell the compiler "hey if the provided value doesn't come from an enum value in this name group throw an error"
Anything else with compiling down to Lua could be done however you see fit but the compiler would just check the provided enum value against those present in the enum name you've specified as the type. And because you'd also need the name (ideally) somewhere in the call to the value it can use that name as well. Nothing would need to be stored in the enum value aside from the number and checking the name would be done based on the actual code you've fed the compiler and not what the code would compile down to (i.e. the actual number/value of the enum value isn't needed for the type check if that makes sense.

[Maiori44]

Could I have an example of valid and invalid code?
It's kinda late so I can't visualize it well

[ashifolfi]

Could I have an example of valid and invalid code? It's kinda late so I can't visualize it well

enum Enum1 {
    Yes,
    No
}

enum Enum2 {
    Yes,
    No
}

Enum1 thing = Enum1.yes // valid as the name comparison checks out and yes is a value in Enum1

Enum1 thing = Enum2.yes // invalid as the value comes from Enum2

Enum1 thing = Enum1.maybe // invalid as maybe is not a value in Enum1

Enum1 thing = Enum3.yes // invalid as Enum3 does not exist

Here's a quick example using C# style names

[Maiori44]

I see, makes more sense now
This could likely be done in 4.0, alongside all the other type things