The second syntax isn't actually enums at all, it's closer to a union type definition. You can't even define enum Colour = Red | Green | Blue using your second syntax.
Programming
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
Yeah I think you've made it worse than Rust in both cases. They clearly shouldn't be strings. And the second option is just unnecessarily confusing.
I hate both of them. The first one is very clunky with all the ". The second one is not self-docummenting at all, and it makes some enums impossible.
For example, you can't represent:
enum A {
B(u32)
C(u32)
D
}
It would be
A {
| u32
| u32
| ()
}
Also, the pipe is very awkward to type, specially depending on keyboard layout. Since it's a rare character. If you need to separate between enums and struts and really don't want to use the enum and struct keywords, you can use different delimiters, like:
A [
u32,
u32
]
B {
u32,
u32
}
Fun Fact: Rust didn't always support leading pipes (which are optional), not even at v1.
Unless I'm hallucinating memories, the support was added with influence from Haskell.
Wait, why literals? Could you not have just Some, without quotes? Or does this syntax imply that enums use these constants as variant tags?
Re: the pipe symbol - i wanted to also use this syntax but have decided against because pipes just looked stranger than commas.
The Idea is that the enum acts as a union, capable of holding any of the member types, It's not that different from using identifiers and when transpiling to rust I will probably only support variants beginning with string literals (or maybe generate them).
The main reason is that I could use type inference to define the variants in a returned anonymous enum.
I like the pipe symbol because it is useful for distinguishing between enums and structs without keywords. And I just personally think it looks better. And allow for pretty anonymous enums like (|String |Int) for something that can accept both a string and an integer.