With the reference resolver planned for the next quarter, I'm considering removing the unescaped version of string literals from the AST. The main motivation for adding it in #195 was to specify the unescaping mechanism precisely. We could still do that in a special-purpose reference function, with tests, for Fluent 1.0, and then move it into the resolver's spec in Q2.
This would be in line with how NumberLiterals only store the raw version of the number, too. See #242. The tooling use-cases that I'm aware of are interested in the raw string mostly, which allows running checks and serializing back to the same Fluent syntax. If the unescaping logic is provided as an independent function, other use-cases could benefit from it to cook the raw string and work with the unescaped one.
With the reference resolver planned for the next quarter, I'm considering removing the unescaped version of string literals from the AST. The main motivation for adding it in #195 was to specify the unescaping mechanism precisely. We could still do that in a special-purpose reference function, with tests, for Fluent 1.0, and then move it into the resolver's spec in Q2.
This would be in line with how
NumberLiteralsonly store the raw version of the number, too. See #242. The tooling use-cases that I'm aware of are interested in the raw string mostly, which allows running checks and serializing back to the same Fluent syntax. If the unescaping logic is provided as an independent function, other use-cases could benefit from it to cook the raw string and work with the unescaped one.