Some time ago, I made a simple LL Parser using enums to build the AST. But I ran into the problem of having to declare extra common fields inside every case of all my enums to store information. For instance, the position field:
enum Expression : AST {
case Number(value: Float, position: (Int, Int))
case BinaryOperation(op: Operator, e1: Expression, e2: Expression, position: (Int, Int))
case UnaryOperation(op: Operator, e: Expression, position: (Int, Int))
}
Now that I've returned to my rusty old project, my curiosity drove me to read many discussions about adding stored values to enums. I disagreed with some of them, but others caught my attetion. Especifically the following comment by @Jumhyn in a thread made by @hisekaldma, who had the exact same problem as I did.
The above proposal with that particular example looks pretty solid and clean to me. I understand people trying to keep enums and structs separeted. But by treating these stored properties just like functions and computed property are treated nowday, I don't see any syntax or technical issue.
Why are these proposals still being rejected? In my opinion, it would add extra power to Swift's already powerful enums.