220 36935 <7b1c3d63-d534-44d2-b4e9-fc0df135fff5@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Thu, 15 Feb 2018 17:32:10 -0800 (PST) Lines: 578 Approved: news@gmane.org Message-ID: <7b1c3d63-d534-44d2-b4e9-fc0df135fff5@isocpp.org> 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_2595_1959301049.1518744731036" X-Trace: blaine.gmane.org 1518744629 13358 195.159.176.226 (16 Feb 2018 01:30:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 01:30:29 +0000 (UTC) Cc: jmckesson@gmail.com, florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBHHJTDKAKGQES6AINOA@isocpp.org Fri Feb 16 02:30:24 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emUqm-0002Cs-5R for gclcip-std-proposals@m.gmane.org; Fri, 16 Feb 2018 02:30:08 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id y144sf929407vky.14 for ; Thu, 15 Feb 2018 17:32:14 -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=nA1xYsIqCtC+aCjd0HG7VqqTdmmCkwm58u+MLKuizRo=; b=a2zoFyZANXqWvaI5TDQCIL4xhsw7LIviOop+MVgOb0R/vqJ9f9om4+FZfGSr1qq6uH 23fjPzAdJv3UX64jibbbW8PF5W+i7fFL4EvLDegKkEWQDLMGvxdQ9XxmOa21BHsL3l1V Ou6EhRx1o1qeh7YlQjv8JQ5GhkdfKojtLXZusSocfn69AQnegiPuGNU06DHZnL/oHk0Z /OSYgrRMOEfMv7ZuN7vDbpd5XsabJymfKop/BRXo/gIQ6YvacUCtNFWX9ZE440mLUOa1 qR/qKvnPuNivrTu7vSpDHRlsKYy+WKANSU5cuwLP8w7UQzDHi60eelpHPI1ZSOnAjwhF 4fNA== 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=nA1xYsIqCtC+aCjd0HG7VqqTdmmCkwm58u+MLKuizRo=; b=BVNGQuHVZZV+apY3rYQ7uTDLyFMlyauc3Hxah41GuNJStMmjgPhK/EXYSxnxqUsOAR PMDjfcBTav4A18Ys1tLg4QaqRRi+ZYB64gWZ6Gs0AGZwETQZVjb4dLAw06gV6SSx0Uvf DurktraCfZQseSbW8KrQQWzo8NXg0dDUuBocizz24BHttXz9AhTmpi2P06Dgq1JKhLD/ PTjVAwazCUCnOtYrVHX3/XGkzL1vJd/46E1WIkLN8EwJHUPHhSbCnVLe5MZij81eKQHs aSSfR37kef0ehYoOCfslQCAu+ZZVYWFwp8/Lfk0PDXeUjq8DjICjaF40M3NcmefAR8mm 4yIQ== 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=nA1xYsIqCtC+aCjd0HG7VqqTdmmCkwm58u+MLKuizRo=; b=eJqaCFrNC3Cfz7DxSEIgdoZJ1YxaEFk+s00698RcCET39Pnkp4Aad0vQZAQq2UFkFe iT0UjUSOXZBigMQ+InuHbaHApd1K2Z8pbEDm8YkO3S/59p0+p7oRFN/9sFm20GP095yK sFEhp54C+m8Qfnt51To5Rlfx77M3GZv0VzXKF2aeI2XsRA3lkPMDylLwvxJD/7ey17mU r+h9cQwximP5dUV0117zzDGiYy9ge72sUqXu0JxDt513RF4Wa9sdypkne1b1VOzWEgwZ jcoq7O+AWOJQejnPdcGrh5DsVxuf2/dSw9EaI+0xJW98zrwXcNODdkUYdhUH5AxcE/1I fBSA== X-Gm-Message-State: APf1xPBsizAPNiGALIBABVOt16msi666U7ONiEf+A5cG910/DITxsYy/ +onUTtd7p/Pm+d/vgukgasyVAA== X-Google-Smtp-Source: AH8x2241N63pzuqSc5ja+nizrXvJYU/Bm0yW/Z3bNZKAyEaZAuM5VdZBrnGrZlLsLWTOJx3/e9mm/w== X-Received: by 10.31.92.20 with SMTP id q20mr3832059vkb.80.1518744733792; Thu, 15 Feb 2018 17:32:13 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.89.3 with SMTP id n3ls103598vkb.21.gmail; Thu, 15 Feb 2018 17:32:12 -0800 (PST) X-Received: by 10.31.171.81 with SMTP id u78mr563225vke.8.1518744731717; Thu, 15 Feb 2018 17:32:11 -0800 (PST) In-Reply-To: <0caab177-cf57-cab1-a5d5-0fc65f651491@gmail.com> X-Original-Sender: jmckesson@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:36935 Archived-At: ------=_Part_2595_1959301049.1518744731036 Content-Type: multipart/alternative; boundary="----=_Part_2596_1879303657.1518744731036" ------=_Part_2596_1879303657.1518744731036 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, February 15, 2018 at 5:54:14 PM UTC-5, 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"{}". > No, I'm mentioning macros taking effect within *string interpolation*. We're talking about the intersection of two things, both of which are still= =20 in question: 1) Arbitrary expressions in interpolation operations. 2) The use of constexpr strings as the *source* for interpolation=20 operations; as the string to be interpolated. That is: constexpr constexpr_string my_func() { constexpr_string a =3D "here's a string {sin(5)}"; //Note: not doin= g=20 interpolation. constexpr_string b =3D " more {foo} string"; //Still not=20 interpolating. return a + b; } auto str =3D std::concat( my_func()); //The above is equivalent to: auto str =3D std::concat("here's a string", sin(5), " more ", foo, " string= "); It's the *combination* of these two things that doesn't work. By the time= =20 the compiler gets around to actually processing the `my_func` call, macro= =20 expansion has come and gone. So how does `sin(5)` get expanded properly? And I know you're thinking that constexpr strings don't exist, that they're= =20 not even really possible. Yet; the committee is working on expansions to=20 constexpr that allow memory allocation. Once that happens, we will have=20 constexpr strings. And once we do, there's no reason you should prevent=20 constexpr strings from being the source of interpolation operations. Well, no reason unless you sandbag interpolation by requiring it to allow= =20 arbitrary expressions. My feeling is that you have to pick one or the=20 other: you either allow arbitrary expressions or you allow constexpr string= =20 interpolation. And if we can only have one, I'd much rather have the latter= .. I want constexpr strings to be equivalent to literals as much as possible. --=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/7b1c3d63-d534-44d2-b4e9-fc0df135fff5%40isocpp.or= g. ------=_Part_2596_1879303657.1518744731036 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thursday, February 15, 2018 at 5:54:14 PM UTC-5= , 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"{}".
=

No, I'm mentioning macros taking effect within string inter= polation.

We're talking about the intersection of two things= , both of which are still in question:

1) Arbitrary expressions in i= nterpolation operations.
2) The use of constexpr strings as the sourc= e for interpolation operations; as the string to be interpolated. That = is:

constexpr constexpr_string<char> my_func()
{
=C2=A0 con= stexpr_string<char> a = =3D "here's= a string {sin(5)}"; //No= te: not doing interpolation.
=C2=A0 constexpr_string<char> b =3D " more {foo} string"; //Still not interpolating.
=C2=A0 return a + b;}=

auto str =3D std::concat(<interpolation syntax> my_func());

//The above is equivalent to:

auto str =3D std::concat(= "here= 's a string", sin(5), " more ", foo, " string");

It's the combinati= on of these two things that doesn't work. By the time the compiler = gets around to actually processing the `my_func` call, macro expansion has = come and gone. So how does `sin(5)` get expanded properly?

And I kno= w you're thinking that constexpr strings don't exist, that they'= ;re not even really possible. Yet; the committee is working on expansions t= o constexpr that allow memory allocation. Once that happens, we will have c= onstexpr strings. And once we do, there's no reason you should prevent = constexpr strings from being the source of interpolation operations.
Well, no reason unless you sandbag interpolation by requiring it to allow = arbitrary expressions. My feeling is that you have to pick one or the other= : you either allow=20 arbitrary expressions or you allow constexpr string interpolation. And=20 if we can only have one, I'd much rather have the latter.

I want= constexpr strings to be equivalent to literals as much as possible.

--
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/7b1c3d63-d534-44d2-b4e9-fc0df135fff5= %40isocpp.org.
------=_Part_2596_1879303657.1518744731036-- ------=_Part_2595_1959301049.1518744731036-- .