On Mon, 16 Oct 2023, 08:55 Hadriel Kaplan via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> > From: Bengt Gustafsson <bengt.gustafsson_at_[hidden]>
>
> > 4. Allowing macro expansion. This is of course a more natural limitation
> > for implementers considering the translation phase you are aiming at.
> > But it is not as obvious for programmers who will certainly picture this
> > as a purely textual transformation, which it basically is. Yes it is
> > probably more work to do this in the earlier parts of the preprocessor,
> > but not overly so. Note that R literals did force preprocessor
> > implementations to be updated, it's not that we never touch the
> > preprocessor.
>
> I agree, it's going to cause surprise. But I think it's unavoidable.
>
> For example:
>
> #define SOME_FLAG 42
> print(X"SOME_FLAG = { SOME_FLAG }");
>
> The programmer will likely expect it to print "SOME_FLAG = 42".
>
> But for it to do that, the preprocessor would need to look in the string,
> determine the "{}" replacement-field portion, and perform expansion within
> *only* that portion.
>
> To make the preprocessor do such a thing, wouldn't that require WG14 to
> agree/approve?
>

No. The C++ standard defines how the preprocessor works in C++.

Implementers might be happier if the preprocessor works the same in C and
C++ but it's not a requirement.





> And if so, wouldn't they just laugh me out of the room? (sorry, I don't
> know how those things go, but I assume it's... unlikely)
>
> -hadriel
>
>
>
> Juniper Public
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>