Store unescaped content in StringLiteral.value and raw content in StringLiteral.raw#203
Conversation
Pike
left a comment
Pike
left a comment
There was a problem hiding this comment.
I'm using .val and .raw_val in compare-locales, and I'm very unhappy about that. Just yesterday had to change one for the other, because the difference isn't obvious.
That said, maybe that's OK within this context, but we'll need comments for that.
Also, please keep the current semantics of .value, as most tools use that and will want to continue to use that.
How about .format_value or .bundle_value for the unescaped value? That indicates the API in which to use that variant?
In |
|
This is technically OK, but I disagree with the choice out of my own experience in compare-locales. Practically, this is going to add a significant risk in particular to the Pontoon support, as we're changing the data the existing Not going to block this, but also not going to r+ this, so removing myself from the review. |
|
Meh, can't find a way to actually remove myself without showing my previous r-. |
Thank you for you comment. I think I'm misunderstanding something here. When we update Pontoon to Syntax 0.8, we'll change the code which deals with |
|
Actually, it looks like updating the serializer to use |
|
My point is that I made the same exact API decision, and it's been a source of bugs (just this week, actually). That said, I don't want to spend more time on this ticket. |
2 participants
This also forbids escape sequences representing surrogate code points, following @Pike's suggestion from #194 (comment). If we allow them, then their handling becomes environment/implementation dependent. E.g. they are ill-formed in the UTF-8 encoding.