Symbols are definitely a really nice feature. But they work better in a dynamic language like Ruby. In Crystal there is essentially no real benefit over using either enums (for a fixed set of values, and also gives type safety) or strings (for dynamic values).
In Crystal, symbols are implemented completely static. They’re essentially converted to integers by the compiler and thus need to be fully known at compile time. You can’t add symbols dynamically by converting a string as in Ruby. Without that, you could only map strings to known symbols. That’s certainly not a desirable solution because it can’t go the full way.
In order to be able to do that, the symbol implementation needs to be completely changed and make symbols essentially equivalent to strings. That’s going to impact performance and reduce the advantage of symbols. Using a hash table won’t be able to mitigate this. All in all, this would make symbols more complex and less useful.
The major use case for symbols right now is for named tuple keys. If we trade away efficiency for flexibility, this use case vanishes, giving even more reason to remove symbols entirely from the language.
Please name a good reason why this should be possible instead of turning the argument around?
In the way this would be implemented, there is no essential difference to simply use strings directly. It would just be a very similar alternative without any major benefits. And it makes it harder to use because people need to decide between both which can be very cumbersome.
In Ruby this is already known to be a problem which resulted in “solutions” like HashWithIndifferentAccess.
Without symbols, there wouldn’t be such problems in the first place.
Matz even tried to remove them from Ruby, but that would break to much code. In Crystal we can do so.
I know it seems hard at first. But when you think about it at bit longer, you’ll notice that you can do very well without symbols. I can’t remember having used a single symbol in Crystal for anything else than named tuples and autocasted enum values.