Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does concatenation work. #10

Open
BengtGustafsson opened this issue Dec 12, 2023 · 1 comment
Open

How does concatenation work. #10

BengtGustafsson opened this issue Dec 12, 2023 · 1 comment

Comments

@BengtGustafsson
Copy link

As of now it is allowed to concatenate cooked and raw literals with the same encoding:

const char* raw = R"(raw)" "cooked";

It is also allowed to specify the encoding on any of concatenated literals, as long as there are no contradictions. The result follows the encoding given, if any.

const wchar_t* mixed = "normal" L"wide";

Example: godbolt

In keeping with this I think we should allow f or x to exist on any of a set of concatenated literals, but obviously only one of them (in case both are available). All expression-fields are collected and placed after the last literal. This combines nicely with the mixes already allowed as exemplified above, so we can write for instance this:

std::wstring str = "One " L" two" f"{1+2}" R"(åäö)" fR"(£€{2+3})";

Here the first literal does not specify anything, the second one specifies the encoding for the concatenated result, the third has an expression-field while the fourth and fifth are raw with the fifth being also a f-literal. The compiler would see:

std::wstring str = std::format(L"One two{}åäö£€{}", 1+2, 2+3);

But with the literal in an internal representation so that any wchar_t characters can be represented. This is done in phase 6.

@BengtGustafsson
Copy link
Author

If prefix UDLs are used as the basis for this we can't just change the encoding with the L as in the second example above, so instead we define that the L, u, U and u8 are built in prefix UDL functions that don't extract any fields. These can't be combined with other prefix UDLs as the preprocessor is not able to know what kind of string literal these are defined for (and they can't be defined for more than one as there is nothing to resolve the resulting ambiguity when not concatenated with a string literal with one of the built in prefixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant