220 36940 article Path: news.gmane.org!.POSTED!not-for-mail From: Florian Lemaitre Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Fri, 16 Feb 2018 10:18:37 +0100 Lines: 827 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> <7b1c3d63-d534-44d2-b4e9-fc0df135fff5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114bb2645977e5056550d40c" X-Trace: blaine.gmane.org 1518772638 32229 195.159.176.226 (16 Feb 2018 09:17:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 09:17:18 +0000 (UTC) Cc: "ISO C++ Standard - Future Proposals" To: Nicol Bolas Original-X-From: std-proposals+bncBC26HM4V3MIRB3WDTLKAKGQEGCFAL3Y@isocpp.org Fri Feb 16 10:17:14 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emc8A-0005ga-26 for gclcip-std-proposals@m.gmane.org; Fri, 16 Feb 2018 10:16:34 +0100 Original-Received: by mail-qt0-f200.google.com with SMTP id s42sf2014693qta.23 for ; Fri, 16 Feb 2018 01:18:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1518772719; cv=pass; d=google.com; s=arc-20160816; b=L/NTwioIV/Ct6/pVAQP8iDoeF+Vv0VBId3xwcrp/3dGcMKRAqo5azPlkzNtyPUSqZ6 JchH/DJb2hdQwY44x/i+t4pV85B0nsebDnzjIt1jY3ZXh8G7O5MLHWkV+VIK4sepfkbi P6Jb/ajXQ2gC6S3LTLRnwgjlI4WFQ/8bQxgWs8BSRo/GxH5Gmi3JYm2OcVyRbqLoC8T8 +ez2jcnQRFWnLNct6fpPLG6jwn2gtZljCIrZZh0lTotQlrjdjCEefhGJzyZ63VmMhxct RD2ssCuE0W6mXnkKIgxC+xPNwCMeLkazq9ivGtogmLZ1u6iH85D7vAdO+BaMleOOabK7 zSnQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:references:in-reply-to:mime-version :arc-authentication-results:arc-message-signature:dkim-signature :arc-authentication-results; bh=GiBJbfg9CeCtbWPLzvhtBxpNZFLyZAp19BLR3wJKf2U=; b=ocwSSUZnQKYTSloRGRvRyOsz1qNIEJxASZGPbRr8+3S5yvt1Ywz7h8Ybx5Dktni2lQ BAYvb09r0wv6/2Kcr50+FGdq2oEF0+zhAfKSnua23K8eZt6At9zjth+7GZUouVV+13kA ooF357KOCBCJLrII8t3G6Pn6fedryT4U/udMt34/dfCKjXG6FzjzgkZ0D/oHePqBiiKC skg1Rypt1/0L0t0qh/c/Rpt8AWHVprmmAwoNSVeQf/uJC1+XoE+IGLCbjntzXNrixWSf FLT6+SFGwxG2zpKqrOaemNO8oY7p+HiA5+I6fiHN60kXhD/QKKL25xwPlNqFzTOtB7md ox6Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PJr8V4BL; spf=pass (google.com: domain of florian.csdt@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=florian.csdt@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=GiBJbfg9CeCtbWPLzvhtBxpNZFLyZAp19BLR3wJKf2U=; b=geuFchiPOWJ+BPXB2Zx0NLeWj9wxUPiefFR1nrw8T7HQNKNqEwaOxHjlVwPrvhxits CuGrXT372n5idj2IQA638YH//HssqTsz/olBvT7vtL3mnY6JMyUg4T8tItPyxzED02bI T2OimBzrnm4dea7dm/QH/1azmmMfdmGuDIJcgcOJVxxYGanRlsZkzFbSVi/EzO18vCWK MnpOzSJ32Cc+gksUqp8WYu/okhab6oG30lW2buqnIZMkWBAMNXmHq3AYX2NLebFpBTVU 0enNaGuSM9q4r4xJ1FQNKuKw83AOdU4T4OTeR2XDCSir0S5nytsE++JirspamSsAVzq6 y0AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=GiBJbfg9CeCtbWPLzvhtBxpNZFLyZAp19BLR3wJKf2U=; b=fhiB1vvJgz2uxYU4w6emVtne/5FkgVQ4grNNKc+NQ5h1y/qGL0L9XJdQu50mJGGap9 XOu80m1rMGHoi9OhEmpjLZjb8AbivIrhgA5sTTIek1npScwPjO0fRmIwo0fx3ENOzT75 pelQ3YifacW60JISZRfBPG6BYHJoovb+Bml0UkVM52xeEi272/mJVctAP7ffQqO/pVOu BjT0MEn7bV9oSVTnSllQv3kKNZcVOB8QqLLZlEqcnlRKS1ylwOaS6Ajq4pf4AahC5jod tZdm4TbWakfj5oVCob14tDVsVq2z3chH+TP0/W6K9s6xC+DQwXfBYJ8sJXI3NF+TsMxK vSOw== X-Gm-Message-State: APf1xPA4VTkjRrfJDDIRB/rsqKRnTPk+HIlITGNsiyoaRa2U30PWnxtQ 3x9GGnqvpGxmpYtTFN6/4nx6LA== X-Google-Smtp-Source: AH8x225iu0/7p7poe78yttAVBn2UCCT+gHe6yZ6nZJAIb/8+0vLOJM9oRyEMM01hqHT9OQVD0ARbvg== X-Received: by 10.55.27.27 with SMTP id b27mr3861603qkb.53.1518772719677; Fri, 16 Feb 2018 01:18:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.200.9.79 with SMTP id z15ls1136944qth.0.gmail; Fri, 16 Feb 2018 01:18:38 -0800 (PST) X-Received: by 10.237.53.40 with SMTP id a37mr9135406qte.96.1518772718439; Fri, 16 Feb 2018 01:18:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518772718; cv=none; d=google.com; s=arc-20160816; b=QwID2O191fXLiIhwMT491mMjndz0NK/Gd0zbRDM5lxobJGkl5jbA8IFztS4Zchn9B9 HZL8qCOxyCQr5a2PeJKc891MPAMC7tJEP1PeKwT9tMXMmyjh+BrzmDsyveke/e4RSfIj bPrUp2l89KyUr+0eG0E5C855qKeDo+zwmss9PmDqULC0QoC+mQQkppHaWs8DYnnXSbz1 V/pwNJkbCI9CjZLGcnJ5XP5Ik1Xni7TrxKNWR/unTB0/r8lLNPNNAs2hP6PugT7jOLKh 1R95Ewpfck1NDHbYrTnn9pYOX2zJmOBGMnJ5hGJAze8/dfe4DbROO7GOgpLf2ErbzCiX aNnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:dkim-signature:arc-authentication-results; bh=N0275FAPdlLbuQ3UXTBoJYzajl0sZoH0ilvtL1dyQGw=; b=RuBDk7m73T9j3dKKiNCMZNc8WmxHCc4tuFqcpMvz3czaMzS0/dbws/8uHD9Tt2RNLU 892tmvMrfR5WV2TPbl4EdvYJEmRxbc9WG2L/VcG6nsAt2k/2nDlX3x+p8qo94iqAK5Z6 TbHhFsbqAQitMB3hyjLE7kNYsvIEqVaBtiL8s9c+u7RDTwsKW/inpZ8uZ+MdfExoW2WR o72XvNTQkIpw7Q5SlM0IcanD2jK1mLaF6Vc9KM6FQ4JZdgZnoDYlMXZnf1fxyuR5+JSQ nhhdLNxo6Sc2ZXbwGnGs1+ruoWIU+RX0fzIvoh+N+Y1o+qefRcuxYBlbq/pRM2A/gU8U wZ8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PJr8V4BL; spf=pass (google.com: domain of florian.csdt@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=florian.csdt@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id n29sor1564270qtl.18.2018.02.16.01.18.38 for (Google Transport Security); Fri, 16 Feb 2018 01:18:38 -0800 (PST) Received-SPF: pass (google.com: domain of florian.csdt@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.200.15.81 with SMTP id l17mr9052904qtk.45.1518772717974; Fri, 16 Feb 2018 01:18:37 -0800 (PST) Original-Received: by 10.200.54.162 with HTTP; Fri, 16 Feb 2018 01:18:37 -0800 (PST) In-Reply-To: <7b1c3d63-d534-44d2-b4e9-fc0df135fff5@isocpp.org> X-Original-Sender: florian.csdt@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=PJr8V4BL; spf=pass (google.com: domain of florian.csdt@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=florian.csdt@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:36940 Archived-At: --001a114bb2645977e5056550d40c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-02-16 2:32 GMT+01:00 Nicol Bolas : > > > On Thursday, February 15, 2018 at 5:54:14 PM UTC-5, Florian Lemaitre wrot= e: >> >> 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, Nicol Bolas a =C3=A9crit = : >>>> >>>> On Thursday, February 15, 2018 at 11:06:10 AM UTC-5, Jake Arkinstall >>>> wrote: >>>>> >>>>> 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 >>>>> as literals, given that they aren't literal and given that they aren'= t >>>>> intended to actually be stored in memory in 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 ne= eds >>>> 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 its= elf >>>>> would likely need to be processed before the constexpr methods themse= lves >>>>> could be evaluated (especially given that they could themselves utili= se >>>>> interpolation). I could be wrong. >>>>> >>>>> I think, at this point, interpolation is a bad word - it made sense i= n >>>>> the initial form, but now this has generalised we might want a new wo= rd 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 othe= r >>>> language features, but in a more open and freeform way. Lambdas for ex= ample >>>> don't have lexical scoping in 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 understoo= d when >>>>> the [insert better name for interpolation] is performed - just the >>>>> resulting type is needed. >>>>> >>>> >>>> The issue with "arbitrary expression" is that you'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 take a compile-time strin= g 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 as easy as just finding a varia= ble >>>> 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 fea= ture >>>> where you're able 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 talking about. This >> isn't standard recursive-descent recursion. This is "execute some conste= xpr >> 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 genuine literals, >> then this isn't much of a problem. Even the macro issue can be sorted ou= t, >> 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 literal= s >>> as a single token or not. If they do, string literal parser will have t= o 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 th= e >> 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 interpolation*. > > We're talking about the intersection of two things, both of which are > still in question: > > 1) Arbitrary expressions in interpolation operations. > 2) The use of constexpr strings as the *source* for interpolation > 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 > doing interpolation. > constexpr_string b =3D " more {foo} string"; //Still not > 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, " stri= ng" > ); > > It's the *combination* 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 know you're thinking that constexpr strings don't exist, that > they're not even really possible. Yet; the committee is working on > expansions to constexpr that allow memory allocation. Once that happens, = we > will have constexpr strings. And once we do, there's no reason you should > prevent constexpr strings from being the source of interpolation operatio= ns. > > 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 arbitrary expressions or you allow constexpr stri= ng > interpolation. And if we can only have one, I'd much rather have the latt= er. > > I want constexpr strings to be equivalent to literals as much as possible= .. > > I get your problem now. Just to simplify my explanations, let's assume that string interpolation is done via a prefix operator called $. You want to be able to call $ on any constexpr string, and also it would be nice to also have expressions in the interpolation pattern. But as you said, having both would trigger the compiler on compiler output, and this would be difficult to handle. I now agree with you on the complexity of having both. What you're describing here looks like some compile-time "eval". constexpr auto call_foo =3D "{foo()}"; // eval: $ call_foo; // translated to: foo(); This looks nasty. It would be possible to leak local variables: int super_private_copy; auto foo(/*whatever equivalent to string literal*/ s) { int super_private =3D 5; return std::concat($ s); } void bar() { foo("{super_private_copy =3D super_private}"); std::cout << "super_private: " << super_private_copy << std::endl; } This little fictive example shows how this would be possible with those assumptions. And this intrinsically bad, independently to the implementation complexity. The outer world should not affect a private scope without its consent. (so this does not apply if some global is used within the private scope: in that case, the access to the global is consented by the private scope) So definitely, having both string interpolation pattern from constexpr strings *and* expressions can be interpolated is conceptually bad. So let's consider only string interpolation pattern from constexpr strings. This also breaks private scope (more tricky though). // intended to use access1, access2, access3 or access4 as pattern auto foo(/*whatever equivalent to string literal*/ s) { int super_secret =3D 5; int access1 =3D 1; int access2 =3D 2; int access3 =3D 3; int access4 =3D 4; return std::make_tuple($ s); } void bar() { auto super_secret =3D std::get<0>(foo("{super_secret}")); std::cout << "super_secret: " << super_secret << std::endl; } Yes, this example is more convoluted, but it still shows what is possible to do. Another thing that could be a problem: what happens if a variable is not declared? It probably should not compile. But then we could have pretty complex and hard to debug code: constexpr auto foo(int i); // returns a "string literal"-like that has the form "{foo###}" where ### is the i-th prime number void bar() { int foo3 =3D 0; do_whatever($ foo(2)); } // This compiles void baz() { int foo4 =3D 0; do_whatever($ foo(2)); } // This doesn't compile (obviously) Why is it different than just access a global variable with the right name? There is no way to know what variables are needed in order to compile other than trying to compile the program. The identifier foo3 is never defined, and never appears in the code (except within your function). Moreover, your local scope now is entangled with the value returned by foo(). (this kind of breaks encapsulation of the local scope) Maybe your fine with this one, but I'm not. That's why I think string interpolation should not apply to constexpr strings (at least, not the interpolation pattern). Don't get me wrong: I am perfectly fine to standardize only string interpolation on actual string literal with only identifiers in patterns, and see later how to improve it. But as far as I'm concerned, I think interpolating constexpr patterns is a bad idea and I would much prefer arbitrary expressions to be interpolated. --=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/CANaF6iikVH-jjGFxx2whvec%3DwcRPeXDwTZSevxD9anWhY= 9zh0g%40mail.gmail.com. --001a114bb2645977e5056550d40c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= 2018-02-16 2:32 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:


On Thursday, February 15, 2018 at 5:54:14 PM UTC-5, Florian Lemai= tre 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 interpolation.

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

1) Arbitrary expr= essions in interpolation operations.
2) The use of constexpr strings as = the source for interpolation operations; as the string to be interpo= lated. That is:

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

auto str = =3D std::concat(<inter= polation 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 combina= tion of these two things that doesn't work. By the time the compile= r gets around to actually processing the `my_func` call, macro expansion ha= s come and gone. So how does `sin(5)` get expanded properly?

And I k= now you're thinking that constexpr strings don't exist, that they&#= 39;re not even really possible. Yet; the committee is working on expansions= to constexpr that allow memory allocation. Once that happens, we will have= constexpr strings. And once we do, there's no reason you should preven= t constexpr strings from being the source of interpolation operations.
<= br>Well, no reason unless you sandbag interpolation by requiring it to allo= w arbitrary expressions. My feeling is that you have to pick one or the oth= er: 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.

I get your problem now.
= Just to simplify my explanations, let's assume that string interpolatio= n is done via a prefix operator called $.

You want to be able to call $ on any constexpr string, and also it would be nice to also have expressions in the interpolation pattern. But as you=20 said, having both would trigger the compiler on compiler output, and=20 this would be difficult to handle.
I now agree with you on the co= mplexity of having both.

What you're describin= g here looks like some compile-time "eval".
constexpr auto call_foo <= /span>=3D "{foo()}";

// eval:
$ call_foo;
<= /span>// translated to:
foo();

This loo= ks nasty.
It would be possible to leak local variables:
=
int super_pr= ivate_copy;

auto foo(/*whatever equivalent to string li= teral*/ s) {
=C2=A0 int super_private =3D 5;
= =C2=A0 return std::concat($ s);
}

void= bar() {
=C2=A0 foo("{super_private_copy =3D super_private}&= quot;);
=C2=A0 std::cout << "super_private: &q= uot; << super_private_copy << std::endl;=
}

This little fictive example shows how this would be possible with those=20 assumptions. And this intrinsically bad, independently to the=20 implementation complexity.
The outer world should not affect a private scope without its consent. (so this does not apply if some=20 global is used within the private scope: in that case, the access to the global is consented by the private scope)


So definitely, having both string interpolation pattern from conste= xpr strings and expressions can be interpolated is conceptually bad.=

So let's consider only string interpolation p= attern from constexpr strings.
This also breaks private scope (mo= re tricky though).
// intended to use access1, access2, access3 or access4 as pat= tern
auto foo(/*whatever equivalent to = string literal*/ s) {
=C2=A0 int super_secret =3D 5;
=C2=A0 int acces= s1 =3D 1;
=C2=A0 int access2 =3D 2;
=C2=A0 int access3 =3D 3;
=C2= =A0 int access4 =3D 4;
=C2=A0 return std::make_tuple($ s);
}

v= oid bar() {
=C2=A0 auto super_secret =3D std::get<0>(foo("{su= per_secret}"));
=C2=A0 std::cout << "super_secret: "= ; << super_secret << std::endl;
}

Yes, this example is more convoluted, b= ut it still shows what is possible to do.

Another = thing that could be a problem: what happens if a variable is not declared? = It probably should not compile.
But then we could have pretty com= plex and hard to debug code:
constexpr auto foo(int i); // returns a = "string literal"-like that has the form "{foo###}" wher= e ### is the i-th prime number

void bar() {
=C2=A0 int foo3 =3D 0= ;
=C2=A0 do_whatever($ foo(2));
} // This compiles

void baz() = {
=C2=A0 int foo4 =3D 0;
=C2=A0 do_whatever($ foo(2));
} // This d= oesn't compile (obviously)

Why is it different than just access a global variable with the right name? There is no way to know what variables are needed in order to compile=20 other than trying to compile the program.
The identifier foo3 is = never defined, and never appears in the code (except within your function).=
Moreover, your local scope now is entangled with the value returned by foo().=20 (this kind of breaks encapsulation of the local scope)

=
Maybe your fine with this one, but I'm not. That's why I think string=20 interpolation should not apply to constexpr strings (at least, not the=20 interpolation pattern).

Don't get me wrong: I= =20 am perfectly fine to standardize only string interpolation on actual=20 string literal with only identifiers in patterns, and see later how to=20 improve it.
But as far as I'm concerned, I think interpolatin= g constexpr patterns is a bad idea and I would much prefer arbitrary=20 expressions to be interpolated.


--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANaF6iikVH-jjG= Fxx2whvec%3DwcRPeXDwTZSevxD9anWhY9zh0g%40mail.gmail.com.
--001a114bb2645977e5056550d40c-- .