You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ASMotor has this feature as a :C format specifier in its interpolations. For example, "{65:C}" gives "A".
It's been occasionally asked-for in RGBASM over the years; I don't recall the specific use cases (most likely to do with metaprogramming or debugging), and it's not a critical feature, but there are times it would be "nice to have".
The main argument against it, I expect, is that there could be more than one charmap to the same value(s). I think any simple consistent tiebreaking logic would be fine in this case (give the first or last defined one, the least or greatest one in strcmp ordering... whatever's most natural to implement, it's an arbitrary choice). There could be an opt-in -Wambiguous-reverse-charmap warning for such cases.
This is slightly complicated by the fact that charmaps can now exist for multiple values, like charmap "A", 1, 2, 3. It would be consistent to allow converting 1, 2, 3 back into "A". I think the natural way to handle this would be a var-arg function.
REVCHAR(65)
MAPCHAR(1, 2, 3)
CHR(42) (Python-esque)
CHARSTR($C3, $A9)
...the name could be bikeshedded
The text was updated successfully, but these errors were encountered:
ASMotor has this feature as a
:C
format specifier in its interpolations. For example,"{65:C}"
gives"A"
.It's been occasionally asked-for in RGBASM over the years; I don't recall the specific use cases (most likely to do with metaprogramming or debugging), and it's not a critical feature, but there are times it would be "nice to have".
The main argument against it, I expect, is that there could be more than one
charmap
to the same value(s). I think any simple consistent tiebreaking logic would be fine in this case (give the first or last defined one, the least or greatest one instrcmp
ordering... whatever's most natural to implement, it's an arbitrary choice). There could be an opt-in-Wambiguous-reverse-charmap
warning for such cases.This is slightly complicated by the fact that charmaps can now exist for multiple values, like
charmap "A", 1, 2, 3
. It would be consistent to allow converting1, 2, 3
back into"A"
. I think the natural way to handle this would be a var-arg function.REVCHAR(65)
MAPCHAR(1, 2, 3)
CHR(42)
(Python-esque)CHARSTR($C3, $A9)
The text was updated successfully, but these errors were encountered: