Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible enum improvements #14

Open
BenjaminNavarro opened this issue Apr 14, 2020 · 6 comments
Open

Possible enum improvements #14

BenjaminNavarro opened this issue Apr 14, 2020 · 6 comments

Comments

@BenjaminNavarro
Copy link
Contributor

After playing a bit with enums I can see two possible improvements:

  1. The str() function on an enumerator returns its numerical value instead of its name, which would be less confusing
  2. Numerical values different from the enum's enumerators can be assigned, leading to an inconsistent state

Examples:

let colors = lang.enum(.red, .green, .blue);
let color = colors.green;
io.println(color);       # prints 1
io.println(color.str()); # prints 1
color = 10;              # no errors
io.println(color);       # print 10, which is not a possible color

I still don't know enough about the internals of the language to know how to fix this, so I prefer create an issue

@Electrux
Copy link
Collaborator

Well, this is in a way, inspired by the C language where enums are nothing but (usually auto assigned) numerical values.
In Feral, enums are no special types. When one declared a variable from an enum value (like you did with color), it actually just creates an integer value.
Usually, when assigning to an enum value's variable (color here), one would just use the enum itself and not assign an arbitrary integer. And when one compares an enum value variable with possible enum values, they would, again, not use the integer values directly.

At least that's how they are designed for Feral. I'd definitely like to know the benefits of printing enums as strings though 🤔

@Electrux
Copy link
Collaborator

Electrux commented Apr 14, 2020

Also, one thing that can be, perhaps, done is that we can have something like
enum_name.val_str(enum_var); for getting the string name of the enum value.
For your example, it would be...

let color = colors.green;
colors.val_str(color); # returns "green"

That being said, I'd still like to know the advantage of this concept with regards to enums (and their usage) 😄.

@BenjaminNavarro
Copy link
Contributor Author

Well, for starters, C enums are a bit broken IMO. I largely prefer C++ enum classes, which are more strict by default (you have to static_cast your way to do unsafe stuff).

Regarding the string part, it would be mostly for introspection. e.g. to print all possible values to the user or finding the corresponding enumerator to a user input. Let's say you parse a configuration file where one field corresponds to an enum. Right now you either have to take numerical values (which is unsafe) or a string an maintaining a map between strings and enumerators (which is not very practical). Having a way to iterate over the enumerators and accessing their numerical value or their name would be great for these situations.

Concerning the assignment from an integer, I get it but I would prefer it to be explicit (as with static_cast) but that's maybe because I'm more into statically typed languages than dynamic ones.

@Electrux
Copy link
Collaborator

That is a good idea. I'll think of something about it perhaps 🤔
It will certainly require a custom type for enums though 😅

@BenjaminNavarro
Copy link
Contributor Author

Take your time for this, it's not like there is an urgent need for this

@Electrux
Copy link
Collaborator

Haha, thanks 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants