220 36930 <96860b9e-95ea-466a-825c-c371844a45e2@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 11:39:29 -0800 (PST) Lines: 275 Approved: news@gmane.org Message-ID: <96860b9e-95ea-466a-825c-c371844a45e2@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1874_349172720.1518723569403" X-Trace: blaine.gmane.org 1518723467 2152 195.159.176.226 (15 Feb 2018 19:37:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Feb 2018 19:37:47 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB46DS7KAKGQECYM56OQ@isocpp.org Thu Feb 15 20:37:43 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emPLT-0007dZ-0J for gclcip-std-proposals@m.gmane.org; Thu, 15 Feb 2018 20:37:27 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id l23sf413800uak.5 for ; Thu, 15 Feb 2018 11:39:32 -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=SAmP25UfqJvnYALw2nrvYN4O3kpmZ7+I8xxjHVyWAfc=; b=evXEdJXVL8gBTjzW8Ynqj53ZOPmXHeIslTSauUyayKWcVBXeamTvpmfwWIP3c2wh/b cdZ2CQfeaj2RE3zdNBxFSRXKRsy1wjGmEG9J4w2jrivuB2JEcUs2FRWAvnLFVs9Bg9WJ znP2GoIU1Ivu11q1lHWQawyGizOMfg8WeW2j0x8aHgd4wYj/1EnfYvHiOwvpRCWusd8l VDgOWuLsch0UHwO/tkgbAxWupGyomvdGVb1E9bI3BIoj3EgxbB7DHrXSrwq2kcjMkiGc vVHM0aRAjBx68RAH2O0+sO7NQ3NSmi22fQoXmdxAsQNjpz4GSfV+KMtvs4HJuNdY9yu/ /tLQ== 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=SAmP25UfqJvnYALw2nrvYN4O3kpmZ7+I8xxjHVyWAfc=; b=HoXMjlrp4wFVtbgS13VafIOf43b3g7bQTOzHpsSg7CMqXGpMd590PYnGcgAJKdWFrs LQgSQ/h8a5X+iCY2DM2uWP1lWuoYmNiodl/GrBu7ZdZg9+aGCmSjMxs9vEQV4Hq6Rt0v JSs4+ChgOEMoA/vpFTvB6c5Hrup8dsznPhGWtmxv1CSKdMvO5KCmU6JDwzV3Eab6s+tI qZoiNkgJpr/AqOdt3E39XGz7hCF/+uWMKTEDm6OO51UPHg4QANJyxx42pOSvaStFRUzL +Gmxx07Sr0BRhbX+OhanukqbHL1Pr63XSWSa9+tnWTvnH5b/sfRSCRiFaKj7ScD7SkK9 39Dw== 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=SAmP25UfqJvnYALw2nrvYN4O3kpmZ7+I8xxjHVyWAfc=; b=k9DodvtgcflThkA4PCNdcs/qFaJzdbxQV3B9HIEVw5b0dMlK/qt7MitdODqtBPHOBj wJCAC1mcbmv2oOEM/Yh60w46IRSLar/XvKgnbp0qpUxL5UWCwMlyE9vpVNqtOfNncs5A XTHys8dcOg7xRgQ1IkD9jvm2SfvusYIS2PWsBpEPQ8bs3EznWezWu1n+Hk3ujC8R1Bzk zUM/OWt6BX32a8qeu/IVh6KuxFCj9t6jBOwP7uVi6qF2w/plkeKq7jE/KxZvV0vinvdd Tr6KAYOm1WeuWjcARWCzAt5prhBbddbBA/YledbmjPlWCEe8hFMwjHi7KO5dOPhIGHwo 7PnQ== X-Gm-Message-State: APf1xPA3Qq0FtzE5iofF5DQd02fdTggmuMKx+pM7C6C08EVBu/laexAt jXbf8VEkIZherUbDyAZLlu83zw== X-Google-Smtp-Source: AH8x226OLwHz1Pus5w63aI0I+d5j8ESb75wSph1Z9kkj2nQEXECb8nXrRVsXkMUNcVcRzhWatFrVSQ== X-Received: by 10.176.22.222 with SMTP id g30mr4376030uaf.10.1518723572474; Thu, 15 Feb 2018 11:39:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.191.147 with SMTP id p141ls366615vkf.19.gmail; Thu, 15 Feb 2018 11:39:30 -0800 (PST) X-Received: by 10.31.160.5 with SMTP id j5mr802376vke.6.1518723570096; Thu, 15 Feb 2018 11:39:30 -0800 (PST) In-Reply-To: <3a738e91-f935-4d11-ab6b-771048b556d4@isocpp.org> 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:36930 Archived-At: ------=_Part_1874_349172720.1518723569403 Content-Type: multipart/alternative; boundary="----=_Part_1875_913364200.1518723569403" ------=_Part_1875_913364200.1518723569403 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, February 15, 2018 at 11:33:26 AM UTC-5, floria...@gmail.com=20 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=20 >> 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= =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 need= s=20 >> them. Things between quotes are literals. >> >> But in terms of constexpr strings, I guess these things themselves can b= e=20 >>> 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 itsel= f=20 >>> would likely need to be processed before the constexpr methods themselv= es=20 >>> could be evaluated (especially given that they could themselves utilise= =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 word= for=20 >>> it. >>> >> >> I don't agree. "String interpolation" often carries the connotation that= =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 language= =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 (other= =20 >>> than their declarations) don't need to be completely understood when th= e=20 >>> [insert better name for interpolation] is performed - just the resultin= g=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 m= uch=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 variabl= e=20 >> with that name. >> >> Not only that, once you get into wanting `constexpr` strings that can be= =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 ar= e=20 > 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 constexpr= =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 to= =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 in= =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. > --=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/96860b9e-95ea-466a-825c-c371844a45e2%40isocpp.or= g. ------=_Part_1875_913364200.1518723569403 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, February 15, 2018 at 11:33:26 AM UTC-5, flori= a...@gmail.com wrote:
Le jeudi 15 f=C3=A9vrier 2018 17:19:29 UTC+1, Nicol Bolas a =C3=A9= crit=C2=A0:
On Thur= sday, February 15, 2018 at 11:06:10 AM UTC-5, Jake Arkinstall wrote:
On 15 Feb 2018 15:51, "Nicol Bolas" <jmck...@gmail.com> wrote:
<= div dir=3D"ltr">
Taking a literal (or possibly constexpr string?)
=

I was wondering whether it makes sense to even describe these thi= ngs as literals, given that they aren't literal and given that they are= n'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 run= time 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 compil= ation, though; I'm under the impression that the expression itself woul= d likely need to be processed before the constexpr methods themselves could= be evaluated (especially given that they could themselves utilise interpol= ation). I could be wrong.

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

I don't agree. "String interpo= lation" often carries the connotation that you're just going to co= ncatenate 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 scop= ing in C++ unless you explicitly ask for them, whereas most languages give = it to you as a matter of course.

(or possibly arb= itrary 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 you're= now requiring the compiler to invoke the compiler. It's easy fo= r the compiler to take a compile-time string and find a variable in scope t= hat matches it. It's much harder (presumably) for the compiler to take = a compile-time string and invoke the compiler on it, within the current sco= pe 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 imagin= e it's as easy as just finding a variable with that name.

Not on= ly that, once you get into wanting `constexpr` strings that can be interpol= ated, you get into lots of issues. Do you really want a feature where you&#= 39;re able to synthesize arbitrary expressions and have someone insinuate t= hem 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 a= lready do that kind of stuff with parentheses. Compilers are by nature recu= rsive.

You don't seem to be fully unde= rstanding what we're talking about. This isn't standard recursive-d= escent recursion. This is "execute some constexpr code and then run th= e compiler on part of its string results." Those "results" m= ight 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 libra= ry 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 `of= fsetof` or similar C-isms?

If we're only going to allow string i= nterpolation with genuine 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, exte= nding such interpolation to constexpr strings would be much more reasonable= ..

I would say that any proposal should be focused on the minimum fea= tureset. It should naturally include expanding into arbitrary expressions a= nd constexpr strings as future directions things could take, but I wouldn&#= 39;t push for them in the short term. Sort of like how `constexpr` function= s 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 lit= erals 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" vari= ant.

--
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/96860b9e-95ea-466a-825c-c371844a45e2= %40isocpp.org.
------=_Part_1875_913364200.1518723569403-- ------=_Part_1874_349172720.1518723569403-- .