220 36944 article Path: news.gmane.org!.POSTED!not-for-mail From: inkwizytoryankes@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Fri, 16 Feb 2018 13:39:41 -0800 (PST) Lines: 653 Approved: news@gmane.org Message-ID: References: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@isocpp.org> <25CCF885-86AD-4D51-8F5C-C46376D34DE0@gmail.com> <4890431.TR9UepuQra@tjmaciei-mobl1> <1cdb6300-7397-46d7-bce9-62e6e8dac40b@isocpp.org> <4bce681e-e729-4124-9322-69291fdb6678@isocpp.org> <758ab0a7-8946-43d4-b2ae-5a4acea11c20@isocpp.org> <01057924-056c-4ee5-a19c-e070d053b982@isocpp.org> <3a738e91-f935-4d11-ab6b-771048b556d4@isocpp.org> <96860b9e-95ea-466a-825c-c371844a45e2@isocpp.org> <0caab177-cf57-cab1-a5d5-0fc65f651491@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4974_86121140.1518817181891" X-Trace: blaine.gmane.org 1518817086 18422 195.159.176.226 (16 Feb 2018 21:38:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 21:38:06 +0000 (UTC) Cc: jmckesson@gmail.com, florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDDLTAGNTIBBBH47TXKAKGQECKZYH3I@isocpp.org Fri Feb 16 22:38:02 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emnhK-0002xf-Gj for gclcip-std-proposals@m.gmane.org; Fri, 16 Feb 2018 22:37:38 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id r4sf945811vke.17 for ; Fri, 16 Feb 2018 13:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=oPGLrPm9j6tT3+4Mn6ouZcTUZtFO8Dxb+VSnEQkWN0w=; b=tgPaJFXbKXS2iRMS9o5neIMRIwkYsqZ93QRXgQ+FUWRoWJjuNBeem9hrLlbH93232R X2RYMoCiezoDDyiE07oqxxp+eAbbxtJag1ipzyK96uEfbcoWhTj8M9iGZ+h7oCtxUQW3 FsXhs10NPO8b/URLzHMAZ1D9OFt6w4A6L6pXUGcDI62mi8F47ZUUUkM9q0qCRGqyp/F8 uLpBbjt2hCtN/O6qIi87+z4kSyFYsK20YSdQVIREpeUkGbYhp6m5qjSH+O/RHhARHZOv cg+AXvSYHJNR4So1jFFszgTFwA7u1dvsqux5C7qwcAuffRhnGg/jtBk+WtSdITxlyN+I aoQA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=oPGLrPm9j6tT3+4Mn6ouZcTUZtFO8Dxb+VSnEQkWN0w=; b=QwrkZt3KUwZwpEFHQu7O2V/3nqOn/AyjFjfrPV591UtPj4cMokKZrit+k3QHVgBUL7 qAsn+1zx5LotRSeOz/9nRhgbMaB6568LD3au4xd4HE46tKSFO07GXdQUD2+mRz0yLlsx iXoeVJOO8eLipiOjnPxpXwwKKKb+uLxQXAnY1V8aaapQttts4i9REMePOgDIQCotaGOc oOlrhS+5dnqaBUqFO2Mor+F8mS2FCxAZq6ZbS+lm+pSWRCGyEBrWIXKxlxAonV35lxlH Jikrn4UyhW+4TNadl6sOG9tGyO2jlXeLf4z1U9kgGD6Nz+VEArnFjx847N9PK18B9Xv5 JxGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=oPGLrPm9j6tT3+4Mn6ouZcTUZtFO8Dxb+VSnEQkWN0w=; b=H0YDUOhI/k3lqol3Du80szOE3DpF71+t0GFLAlPOpV50WhcKZ728CqNVbesI6GOqqe hrJyFDoWc9Kaf2JDZkNqytT82x8R9sHP5lqqZygGcSoZUfw61977cBiOY93UT8Na1eom YlSrlOeGdb+G8K9rLRE831PbF44tD60rP5yYa6qPbqIMOJId6s12SzhDsYrf3/ippuwA WKA4bTz9irwNtfJLSTEx9PT8mc/YTzEmhc3bPwpyXbBUq9Zn2bhgl9HntmO2Uosv9ULu JVNlsQKAnjoDhqlQhHryvFy1oC2LEbV02lYk4IokBWlxxl0Sk1gT7oqZUX8WQppSvBol xg6w== X-Gm-Message-State: APf1xPAFQyeORIN3d+F6kdz4f/QUuwq5MYrhn4ScI4n8xok4fItMeMtP ncVpcqXWzdRqlfdE/YzvMej99A== X-Google-Smtp-Source: AH8x226eSiqD/CZXJ6rHXKiSTEwqgoSV6brevI7alBSUFnMepqypourPV2exNskJaG9BvaTvKsF7Vw== X-Received: by 10.176.84.197 with SMTP id q5mr3713607uaa.114.1518817184442; Fri, 16 Feb 2018 13:39:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.164.68 with SMTP id n65ls1773697vke.0.gmail; Fri, 16 Feb 2018 13:39:42 -0800 (PST) X-Received: by 10.31.128.137 with SMTP id b131mr1158612vkd.7.1518817182596; Fri, 16 Feb 2018 13:39:42 -0800 (PST) In-Reply-To: <0caab177-cf57-cab1-a5d5-0fc65f651491@gmail.com> X-Original-Sender: inkwizytoryankes@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:36944 Archived-At: ------=_Part_4974_86121140.1518817181891 Content-Type: multipart/alternative; boundary="----=_Part_4975_1051887967.1518817181892" ------=_Part_4975_1051887967.1518817181892 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, February 15, 2018 at 11:54:14 PM UTC+1, Florian Lemaitre wrote= : > > On 15/02/2018 20:39, Nicol Bolas wrote: > > On Thursday, February 15, 2018 at 11:33:26 AM UTC-5, floria...@gmail.com= =20 > wrote:=20 >> >> Le jeudi 15 f=C3=A9vrier 2018 17:19:29 UTC+1, Nicol Bolas a =C3=A9crit := =20 >>> >>> On Thursday, February 15, 2018 at 11:06:10 AM UTC-5, Jake Arkinstall=20 >>> wrote:=20 >>>> >>>> On 15 Feb 2018 15:51, "Nicol Bolas" wrote: >>>> >>>> Taking a literal (or possibly constexpr string?) >>>> >>>> >>>> I was wondering whether it makes sense to even describe these things a= s=20 >>>> literals, given that they aren't literal and given that they aren't=20 >>>> intended to actually be stored in memory in any way. >>>> >>> >>> We still call literals "literals", even if you use them entirely at=20 >>> compile-time via `constexpr` tricks, such that no runtime code ever nee= ds=20 >>> them. Things between quotes are literals. >>> >>> But in terms of constexpr strings, I guess these things themselves can= =20 >>>> be built up by other methods - I'm not sure if this makes sense in=20 >>>> compilation, though; I'm under the impression that the expression itse= lf=20 >>>> would likely need to be processed before the constexpr methods themsel= ves=20 >>>> could be evaluated (especially given that they could themselves utilis= e=20 >>>> interpolation). I could be wrong. >>>> >>>> I think, at this point, interpolation is a bad word - it made sense in= =20 >>>> the initial form, but now this has generalised we might want a new wor= d for=20 >>>> it. >>>> >>> >>> I don't agree. "String interpolation" often carries the connotation tha= t=20 >>> you're just going to concatenate strings, but it doesn't *have* to. C++= =20 >>> sometimes defines concepts with names that are similar to other languag= e=20 >>> features, but in a more open and freeform way. Lambdas for example don'= t=20 >>> have lexical scoping in C++ unless you explicitly ask for them, whereas= =20 >>> most languages give it to you as a matter of course. >>> >>> (or possibly arbitrary expressions?) >>>> >>>> >>>> This wouldn't be so much of a problem, because those expressions (othe= r=20 >>>> than their declarations) don't need to be completely understood when t= he=20 >>>> [insert better name for interpolation] is performed - just the resulti= ng=20 >>>> type is needed. >>>> >>> >>> The issue with "arbitrary expression" is that you're now requiring the= =20 >>> compiler to *invoke the compiler*. It's easy for the compiler to take a= =20 >>> compile-time string and find a variable in scope that matches it. It's = much=20 >>> harder (presumably) for the compiler to take a compile-time string and= =20 >>> invoke the compiler on it, within the current scope as if it had been= =20 >>> written text. >>> >>> I'm not saying its impossible; I don't know much about compiler=20 >>> architecture. But I can't imagine it's as easy as just finding a variab= le=20 >>> with that name. >>> >>> Not only that, once you get into wanting `constexpr` strings that can b= e=20 >>> interpolated, you get into lots of issues. Do you really want a feature= =20 >>> where you're able to synthesize arbitrary expressions and have someone= =20 >>> insinuate them into their code at compile time? >>> >>> Or... maybe you do? >>> >> >> From what I know about compilation and formal languages in general, it= =20 >> shouldn't be very hard for a compiler to deal with expressions within=20 >> `F"{}"`. >> The compiler already do that kind of stuff with parentheses. Compilers= =20 >> are by nature recursive. >> > > You don't seem to be fully understanding what we're talking about. This= =20 > isn't standard recursive-descent recursion. This is "execute some constex= pr=20 > code and then run the compiler on part of its string results." Those=20 > "results" might include things like *macros*, and macro expansion is=20 > supposed to have happened long before executing constexpr functions. > > And you can't just say they're expressions minus macros. Many C-standard= =20 > library facilities are, or might be, macros after all. Is it legal to do= =20 > `F"{sin(foo)}"`? If string interpolation is supposed to allow arbitrary= =20 > expressions, it would be odd indeed if it were not. What about invoking= =20 > `offsetof` or similar C-isms? > > If we're only going to allow string interpolation with genuine literals,= =20 > then this isn't much of a problem. Even the macro issue can be sorted out= ,=20 > since the string is right there in the text of the source code. > > But if we want string interpolation to ever be applied to the results of= =20 > compile-time execution, that's going to be *much* more complex if string= =20 > interpolation can handle arbitrary expressions. Whereas if we define it t= o=20 > just be variable identifiers, extending such interpolation to constexpr= =20 > strings would be much more reasonable. > > I would say that any proposal should be focused on the minimum featureset= ..=20 > It should naturally include expanding into arbitrary expressions and=20 > constexpr strings as future directions things could take, but I wouldn't= =20 > push for them in the short term. Sort of like how `constexpr` functions i= n=20 > C++11 were really limited, which C++14 greatly expanded. > > The only thing I don't know is if the compiler deals with string literals= =20 >> as a single token or not. If they do, string literal parser will have to= be=20 >> modified quite a lot, even with the "identifier-only" variant. >> > > First thing first, currently the C++ is oblivious to the preprocessor, an= d=20 > this will probably not change in the forseeable future (note that the=20 > preprocessor is somehow aware of C++: __cplusplus macro, #include,=20 > __has_cpp_attribute...). > But as far as the compiler is concerned, these are two distinct steps tha= t=20 > are processed one after the other, without going back. > > Maybe you want to change that, but I think you were mentionning macros=20 > taking effect within F"{}". > For instance: > #define Foo 5 > F"{Foo}"; > would expand to: > F"{5}"; > > This has basicaly nothing to do with C++, just the preprocessor should be= =20 > aware that F"{ and }" are somehow similar to parentheses and it should=20 > process the inner part as usual. > I am simplifying here, but the idea is there. No coming back from C++ to= =20 > the preprocessor here. > > If this is not what you have in mind, please correct me. > > This is impossible, macros can't work with interpolation (at least not in= =20 broken way). Consider this code: #define X C}E F"A{X}B"; // `"A", C , " E}B"` #define Y(X) F"A{X}B"; Y(a}Y{c); // `"A", a, "Y", c, "B"` #define Z {B F"A{Z}C"; // `"A{B}C"` normal string! #define W(A, B) F"{A B}" W({{, b) // `"{", b` W(a}, b) // `a, " B}"` or `a, " b}"`? W({, b) // `"{ b}"` or `"{ B}"`? #define LL(P, A) P##"{A}" LL(F, a) // `F"{A}"` or `F"{a}"`? #define RR(_HERE_) FR"{AA}( A ){_HERE_}" FR"{AA}( B ){AA}" //second `FR`=20 should be part of raw string, true end is last `){AA}"` RR(AA) // `FR"{AA}( A ){AA}" FR"{AA}( B ){AA}"` =3D> `F" A " F" B "` =3D> `= F" A=20 B "` or `F" A ){AA}\" FR\"{AA}( B "`? This will be pain in a** to implement, probably lot of easier will be by=20 replacing `{` by `"`, at least all tools and processor will be easier to=20 adjust to support this. Then why not this work this way: F"A "b" B "c" D"_postfix But this could have confusing part that last symbol is postfix or variable= =20 named `_postfix`? --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/ddf515c9-70f6-401b-93eb-b412128779a0%40isocpp.or= g. ------=_Part_4975_1051887967.1518817181892 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thursday, February 15, 2018 at 11:54:14 PM UTC+= 1, Florian Lemaitre wrote:
=20 =20 =20
On 15/02/2018 20:39, Nicol Bolas wrote:
On Thursday, February 15, 2018 at 11:33:26 AM UTC-5, floria...@gmail.com wrote:
Le jeudi 15 f=C3=A9vrier 2018 17:19:29 UTC+1, Ni= col Bolas a =C3=A9crit=C2=A0:
On Thursday, February 15, 2018 at 11:06:10 AM UTC-5, Jake Arkinstall wrote:
On 15 Feb 2018 15:51, "Nicol Bolas" <j= mck...@gmail.com> wrote:
Taking a literal (or possibly constexpr string?)

I was wondering whether it makes sense to even describe these things as literals, given that they aren't literal and given that the= y aren't intended to actually be stored in memory i= n any way.

We still call literals "literals", even if you = use them entirely at compile-time via `constexpr` tricks, such that no runtime code ever needs them. Things between quotes are literals.

But in terms of constexpr strings, I guess these things themselves can be built up by other methods - I'm not sure if this makes sense in compilation, though; I'm under the impression that the expression itself would likely need to be processed before the constexpr methods themselves could be evaluated (especially given that they could themselves utilise interpolation). I could be wrong.

I think, at this point, interpolation is a bad word - it made sense in the initial form, but now this has generalised we might want a new word for it.

I don't agree. "String interpolation" often= carries the connotation that you're just going to concatenate strings, but it doesn't have to. C++ sometimes defines concepts with names that are similar to other language features, but in a more open and freeform way. Lambdas for example don't have lexical scoping i= n C++ unless you explicitly ask for them, whereas most languages give it to you as a matter of course.

(or possibly arbitrary expressions?)

This wouldn't be so much of a problem, because those expressions (other than their declarations) don't need to be completely understood when the [insert better name for interpolation] is performed - just the resulting type is needed.

The issue with "arbitrary expression" is that y= ou're now requiring the compiler to invoke the compiler. It's easy for the compiler to take a compile-time string and find a variable in scope that matches it. It's much harder (presumably) for the compiler to tak= e a compile-time string and invoke the compiler on it, within the current scope as if it had been written text.

I'm not saying its impossible; I don't know much = about compiler architecture. But I can't imagine it's a= s easy as just finding a variable with that name.

Not only that, once you get into wanting `constexpr` strings that can be interpolated, you get into lots of issues. Do you really want a feature where you're abl= e to synthesize arbitrary expressions and have someone insinuate them into their code at compile time?

Or... maybe you do?

From what I know about compilation and formal languages in general, it shouldn't be very hard for a compiler to deal with expressions within `F"{}"`.
The compiler already do that kind of stuff with parentheses. Compilers are by nature recursive.

You don't seem to be fully understanding what we're talki= ng about. This isn't standard recursive-descent recursion. This is "execute some constexpr code and then run the compiler on part of its string results." Those "results" might= include things like macros, and macro expansion is supposed to have happened long before executing constexpr functions.

And you can't just say they're expressions minus macros. = Many C-standard library facilities are, or might be, macros after all. Is it legal to do `F"{sin(foo)}"`? If string interpolation is supposed to allow arbitrary expressions, it would be odd indeed if it were not. What about invoking `offsetof` or similar C-isms?

If we're only going to allow string interpolation with genuin= e literals, then this isn't much of a problem. Even the macro issue can be sorted out, since the string is right there in the text of the source code.

But if we want string interpolation to ever be applied to the results of compile-time execution, that's going to be much= more complex if string interpolation can handle arbitrary expressions. Whereas if we define it to just be variable identifiers, extending such interpolation to constexpr strings would be much more reasonable.

I would say that any proposal should be focused on the minimum featureset. It should naturally include expanding into arbitrary expressions and constexpr strings as future directions things could take, but I wouldn't push for them in the short term. Sort of like how `constexpr` functions in C++11 were really limited, which C++14 greatly expanded.

The only thing I don't know is if the compiler deals with string literals as a single token or not. If they do, string literal parser will have to be modified quite a lot, even with the "identifier-only" variant.

First thing first, currently the C++ is oblivious to the preprocessor, and this will probably not change in the forseeable future (note that the preprocessor is somehow aware of C++: __cplusplus macro, #include, __has_cpp_attribute...).
But as far as the compiler is concerned, these are two distinct steps that are processed one after the other, without going back.

Maybe you want to change that, but I think you were mentionning macros taking effect within F"{}".
For instance:
#define Foo 5=
F"{Foo}";
would expand to:
F"{5}";

This has basicaly nothing to do with C++, just the preprocessor should be aware that F"{ and }" are somehow similar to pare= ntheses and it should process the inner part as usual.
I am simplifying here, but the idea is there. No coming back from C++ to the preprocessor here.

If this is not what you have in mind, please correct me.


This is impossible, macros can= 9;t work with interpolation (at least not in broken way).
Consider this = code:

#define X C}E
F"A{X}B"; // `&q= uot;A", C , " E}B"`

#define Y(X) F"A{X}B";
Y(a}Y{c); // `"A", a, &q= uot;Y", c, "B"`


#define Z {B
F"A{Z}C"; = // `"= A{B}C"` normal string!

#define W(A, B) F"{A B}"
W({{, b) //= `"{", b`
W(a}, b) // `a, " B}"` or `a, " b}"= `?
W({, b) // `"{ b}"` or `"{ B}"`?

#define= LL(P, A) P#= #"{A}"
LL(F, a) // `F"{A}"` or `F"{a}"`?=

#define RR(_HERE_) FR"{AA}( A ){_HERE_}" FR"{AA}( B ){AA}" //second `FR` should be part of raw s= tring, true end is last `){AA}"`
RR(AA) <= /span>// `FR"= ;{AA}( A ){AA}" FR"{AA}( B ){AA}"` =3D> `F" A "= F" B "` =3D> `F" A =C2=A0B "` or `F" A ){AA}\&= quot; FR\"{AA}( B "`?


This will be pain in a** to implement, probably lot of easier will be by r= eplacing `{` by `"`, at least all tools and processor will be easier t= o adjust to support this.
Then why not this work this way:
= F"A "b" B "c" D"_postfix
But this could have confusing part that last symbol is postfix or variab= le named `_postfix`?








--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/ddf515c9-70f6-401b-93eb-b412128779a0= %40isocpp.org.
------=_Part_4975_1051887967.1518817181892-- ------=_Part_4974_86121140.1518817181891-- .