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
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.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: