Add Enum.parse(Bytes) and Enum.parse?(Bytes) - #17175
Conversation
| slice.each do |byte| | ||
| next if byte == '-'.ord || byte == '_'.ord | ||
| byte_counter += 1 | ||
| return nil if byte_counter > {{max_size}} |
There was a problem hiding this comment.
issue: We cannot compare a byte index with a char size.
As mentioned above, there is no StringLiteral#bytesize equivalent. So keeping this optimization is a bit tricky. Perhaps we could calculate the max bytesize at runtime?
But it should be fine to just use max_size * 4 as limit, same as for the buffer size.
There was a problem hiding this comment.
Good point. I didn't think about enum members with non-ASCII names. There weren't any tests for them, so I added some, including a couple with case-folding, in e3a80b8.
A discussion for another time is whether we should add support for Bytes to Char::Reader. Or maybe some different construct that's allocated on the stack since I'm not sure how to articulate my thoughts on this, but the summary is that I've now implemented parsing bytes into UTF-8 chars in two different PRs (here and in #17065) and that feels like we need a better abstraction.Char::Reader is a reference type and we're trying to avoid heap allocations.
There was a problem hiding this comment.
Char::Reader is a struct with value semantics
There was a problem hiding this comment.
Oh, I must've gotten it confused with something else. We can disregard that part, then.
Using strings, we had support for that out of the box, but we had to recreate it for byte-parsing.
Co-authored-by: Johannes Müller <straightshoota@gmail.com>
|
While the feature is nice, it also duplicates the whole Unicode parsing that is already implemented for String 😢 Maybe we should re-think the current String methods that actually operate on Bytes internally. There could be an abstraction layer to iterate every Char in Bytes (Unicode aware), to parse "123" into an Int32, ... The |
4 participants
Fixes #17174