> From: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>

> 5. Escaping of quotation marks in the expressions. I'm a bit unsure of
> what is the best choice, but if handling of f/x literals is moved to an
> earlier stage of the preprocessor it would be _possible_ to handle
> quotation marks without quoting them. I think it would be an advantage
> to be able to write the expressions exactly the same as if they were
> outside the f/x literal. There is also a problem with parentheses inside
> such quotes (escaped or not) that needs to be discussed if "matching
> parentheses" is employed. For instance:
> F"{isLeft ? "(" : ")"}"
> or with escaping of
> F"{isLeft ? \"(\" : \")\"}"

If you don't require escaping inner quotes, then you need a delimiter to determine where the f/x-string token ends - such as what the R"" raw-string does by requiring the parentheses:

    F"({isLeft ? "(" : ")"})"

And since there's already a `)"` in there, it would actually require the optional d-char-sequence to be used:

    F"=({isLeft ? "(" : ")"})="

And to make matters more complicated, that colon in the middle would be treated as a format-spec delimiter, so it really needs to be:

    F"=({(isLeft ? "(" : ")")})="


Obviously that's what supporting an R raw-string would allow the user do anyway:

    FR"=({(isLeft ? "(" : ")")})="

And I think this is what a programmer would expect for non-R/default:

    F"{(isLeft ? \"(\" : \")\")}"

Because that's what their existing format strings look like today.

And a lot of editors/IDEs/etc. highlight such escapes correctly already today, obviously, so it's not as bad as it looks in email. :)


>There is also the worst case scenario when the embedded string literal
> contains an escaped quote, for instance:
> F"{isSingle ? "'" : "\""}"
> or with escaping, I don't think this can work:
> F"{isLeft ? \"'\" : \"\"\"}"
> The problem here is that the escaping incurred by being inside a f/x
> literal crashes with the need to escape the quote in the expression
> being inserted. Parsing becomes (close to?) impossible.

Wouldn’t this work?:

    F"{(isLeft ? \"'\" : \"\\\"\")}"

f/x-string replacement-field parsing would be operating on a `(isLeft ? "" : "\"")` substring, no? (or does the unescaping happen later?)

Regardless, I think I actually prefer your next suggestion:

> The alternatives is to further restrict the embedded expressions not
> allowing quoted strings in them ...

I'm fine with that. The spec can always add support for them later, without breaking backwards-compat.

-hadriel



Juniper Public