On 26/10/2023 10:55, Jₑₙₛ Gustedt wrote:

>> I've been asked to see what would be the general WG14 feelings
>> towards an extension of the C preprocessor to enable implementation
>> of F-strings. Here is the C++ focused draft paper:
>>
>> http://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/hadrielk/cpp-proposals/main/f-string/f-string-r2.bs#c-usage
>
> Interesting.
>
> But before we go into the specific details or goals that this paper
> tries to achieve (which are all interesting by themselves) I would
> like to take back a step concerning syntax of the preprocessor.
>
> I don't know how this exactly works in C++, but in C prefixes of
> strings and suffixes of number constructs are not symmetrical. Whereas
> for suffixes basically any *identifier* glued to a number would
> survive preprocessing, for prefixes the only allowed currently are
> `L`, `u`, `u8` and `U`.
>
> This caused some problems when C introduced `U` because previously
> `U"something"` was read by the preprocessor as two tokens, an
> identifier followed by a string. This could be valid in some cases
> where there was a macro `U` that did some fancy stuff, and so some
> code changed semantics from one version of C to the next.
>
> So maybe, before thinking of special cases like in the proposed paper,
> we should first think of widening the notion of string in the
> preprocessor, gluing any directly preceding identifier into the same
> token. I wouldn't expect this to be very controversial, but this would
> then give us the grounds to come up with a particular meaning for any
> of these. I think this would be a good move for ensuring compatibility
> between C and C++, anyhow.
>
> BTW, I was think of using such things for other purposes, namely a
> small `x` prefix for binary strings (`x"o\xab"` otherwise interpreted
> as usual but of type `unsigned char const[]`) and `B` for base64
> encoded binary strings.

That all looks good, but that's definitely detail you guys could help
him directly with after he formally submits.

He had been thinking WG21 you see and asked me for advice on how to
proceed with the process which would be involved if proceeding through
WG21. The fact his proposal is so heavily based on extending the C
preprocessor, well it seemed to be it might be a better fit for WG14 if
you guys were open to a `sprintf()` replacement. This I thought worth
checking here.

Anyway, let's see if he iterates his proposal and in what direction.

Thanks for the feedback everyone.

Niall