Date: Mon, 16 Oct 2023 05:56:19 +0000
> From: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>
> 3. Not allowing combination with R for raw literals. It seems like there
> is no real reason not to allow this. The purpose of R literals is to be
> able to have quotes and newlines in strings literals. You can use a R
> literal as the format string for std::format so it seems odd to not
> allow combining f/x and R, in which case the F or X would go between any
> U prefix and the R which must be last.
Right, I knew this topic would come up. :)
This would definitely be up to opinions/consensus, because as far as I'm aware there is nothing preventing us from doing exactly what you say, from a technical perspective.
I chose to limit it in the draft because I was trying to keep the f/x-format-string parsing to be done in a very early a phase of translation - *before* phase-7 evaluation. In fact I was originally going to propose this stuff be done immediately after preprocessing, either after phase-4 or after phase-5.
As far as I'm aware, raw-strings and various encodings don't get evaluated until phase-7. So for example, the raw-string string-literal `R"( \u00)"` does not become the string literal object "41" until phase-7.
Since we would want the x-string parsing to operate on the evaluated string "41", I was originally trying to avoid needing that evaluation done.
But yeah, I've gotten some feedback offline that the x-string parsing should be done in a later phase anyway.
As an aside: I don't personally care when it's done, to be honest - I was trying to keep it as trivial/simple as possible for compilers to implement, and the WG to standardize. But I may be very wrong/misguided about this doing that.
-hadriel
Juniper Public
> 3. Not allowing combination with R for raw literals. It seems like there
> is no real reason not to allow this. The purpose of R literals is to be
> able to have quotes and newlines in strings literals. You can use a R
> literal as the format string for std::format so it seems odd to not
> allow combining f/x and R, in which case the F or X would go between any
> U prefix and the R which must be last.
Right, I knew this topic would come up. :)
This would definitely be up to opinions/consensus, because as far as I'm aware there is nothing preventing us from doing exactly what you say, from a technical perspective.
I chose to limit it in the draft because I was trying to keep the f/x-format-string parsing to be done in a very early a phase of translation - *before* phase-7 evaluation. In fact I was originally going to propose this stuff be done immediately after preprocessing, either after phase-4 or after phase-5.
As far as I'm aware, raw-strings and various encodings don't get evaluated until phase-7. So for example, the raw-string string-literal `R"( \u00)"` does not become the string literal object "41" until phase-7.
Since we would want the x-string parsing to operate on the evaluated string "41", I was originally trying to avoid needing that evaluation done.
But yeah, I've gotten some feedback offline that the x-string parsing should be done in a later phase anyway.
As an aside: I don't personally care when it's done, to be honest - I was trying to keep it as trivial/simple as possible for compilers to implement, and the WG to standardize. But I may be very wrong/misguided about this doing that.
-hadriel
Juniper Public
Received on 2023-10-16 05:56:30