220 36928 <3a738e91-f935-4d11-ab6b-771048b556d4@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Thu, 15 Feb 2018 08:33:26 -0800 (PST) Lines: 208 Approved: news@gmane.org Message-ID: <3a738e91-f935-4d11-ab6b-771048b556d4@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1371_343370368.1518712406607" X-Trace: blaine.gmane.org 1518712290 29050 195.159.176.226 (15 Feb 2018 16:31:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Feb 2018 16:31:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBV7MS3KAKGQEVTK4ETQ@isocpp.org Thu Feb 15 17:31:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emMRP-00074K-5L for gclcip-std-proposals@m.gmane.org; Thu, 15 Feb 2018 17:31:23 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id j200sf140139vkd.3 for ; Thu, 15 Feb 2018 08:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=OkuuHDhJqN8zuh9IbU2EU0ziwTrzwIkdr8XEmTeW8bM=; b=q7vLdlbLbY0g8iYYPvLWT1kEN4jjJyY8qRH3wgbgobZXlNdFrGQ4gHMrxMdIm6XKXG XeaQc+edA/uIO907IaPyUl1oH1BoDoedN2oa9psY2XP6rYggsSXpr/A0ldT2QbWTJjHj AxZv2YZNhMpfUy2DfoZdS4OLhMP0M7JMa4seLGMawxeOyG7TC0X6i9NKlCh3+4uVvX9d p8r41SNzCnaoMeW7VR9sNAVOlwK3BsMWEC+A+Sn+uuy2VepS19WFPNmdNY10KR6IDLEt eeUvQFeM3RKJww6yvwxcZGQXWOamkzvaeeJI1gJHdVW50h/MM5qLJzbQVavtoI3UomoA 5E2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to: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=OkuuHDhJqN8zuh9IbU2EU0ziwTrzwIkdr8XEmTeW8bM=; b=G4B8EUsmo0lJsBkVDOtXS9GnFOJAH9xvDKffoSxeklIaTq6T9cSYHeKK3KCaTZRYUn uxMv/xiYlobvk2oeBmKYrOlFczVNf63MhXP6kPjo4Mq7eANLTHB2xwb8x91pqATUmQE5 1Ybw7VjBKCYTTY4f21l9vYG1fOWVUlRppLKahfnyLA0h91DAt9uxvi0gcSuTzgppl0Q2 5mVTEjx0aYiM4Sfsp02rkC3DelVj1eelb6x/SUKi0e3MvNdERzUJeu6H0Cd1ha60qdyX eunePtR8ZSpKZNiHr+Kv/PQqYq0Su/GQAjuForu6ygAhFv4+c1GhrlM9P1kzSNMPRPI1 K5kg== 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: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=OkuuHDhJqN8zuh9IbU2EU0ziwTrzwIkdr8XEmTeW8bM=; b=bICyPLzy5vjcMJJBfpWTzKzkqSx8FHjHWOXOK2AwmDBX2pfXMS4QDw3Xxe0WERxkov 6aDPAzyU516yG7ElIhdy43OejZHlE48rpLghd2g96dbanbdDv05t6is9leMSBZHQsA4k onCfvM+5AX0gHrFCBq3aMfBAzlaaAJu58Wkk72pIR+POBGdbCWx366BE05aieSpiGdU/ 22GN7e5FK7oxTM5TlHSkmCXMHCVoNDSsXGHRjrsJqKSN4xSexqoglC+knbdnJVSkMHfw A/QAEEYV2qnLee4VRzqVC9w6Vh3Z/Pas86uSm7FNBA4kLqu/He64KrGsEvXdzFKWkagN I/UQ== X-Gm-Message-State: APf1xPBdC8uEjBEImJgGznH8OyrpHvr3IBSyCLSTuBxWbDRduhsXoiAs CeLCEX731Ihnb7lwhUrcJx7zPQ== X-Google-Smtp-Source: AH8x226Nq8+xEnMGRkAYdkqi57ArZOaXFVEZW2mq9YrSs8gT9pJqwZd1nHyte2dFKFOusgMOvPN6YA== X-Received: by 10.176.36.195 with SMTP id k3mr2057757uan.97.1518712409048; Thu, 15 Feb 2018 08:33:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.168.77 with SMTP id r74ls77173vke.17.gmail; Thu, 15 Feb 2018 08:33:27 -0800 (PST) X-Received: by 10.31.54.205 with SMTP id d196mr750703vka.14.1518712407080; Thu, 15 Feb 2018 08:33:27 -0800 (PST) In-Reply-To: X-Original-Sender: florian.csdt@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:36928 Archived-At: ------=_Part_1371_343370368.1518712406607 Content-Type: multipart/alternative; boundary="----=_Part_1372_1055808211.1518712406608" ------=_Part_1372_1055808211.1518712406608 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrot= e: >> >> 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 needs= =20 > them. Things between quotes are literals. > > But in terms of constexpr strings, I guess these things themselves can be= =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 itself= =20 >> would likely need to be processed before the constexpr methods themselve= s=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 the= =20 >> [insert better name for interpolation] is performed - just the resulting= =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 mu= ch=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 variable= =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 are= =20 by nature recursive. 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/3a738e91-f935-4d11-ab6b-771048b556d4%40isocpp.or= g. ------=_Part_1372_1055808211.1518712406608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le jeudi 15 f=C3=A9vrier 2018 17:19:29 UTC+1, Nico= l Bolas a =C3=A9crit=C2=A0:
On Thursday, February 15, 2018 at 11:06:10 AM UTC-5, Jake Ark= install wrote:
On 15 Feb 2018 15:51, "Nicol Bolas&q= uot; <jmck...@gmail.com> wrote:
Taking a literal (or possibly con= stexpr 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` trick= s, such that no runtime code ever needs them. Things between quotes are lit= erals.

But in terms of constexpr strings, I guess these thing= s themselves can be built up by other methods - I'm not sure if this ma= kes sense in compilation, though; I'm under the impression that the exp= ression itself would likely need to be processed before the constexpr metho= ds themselves could be evaluated (especially given that they could themselv= es 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 wa= nt a new word for it.

I don't agree. &= quot;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 in C++ unless you explicitly ask for them, whereas m= ost languages give it to you as a matter of course.

(or possibly arbitrary expressions?)

This wouldn't be s= o much of a problem, because those expressions (other than their declaratio= ns) 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 for the compiler to take a compile-time string and find a = variable in scope that matches it. It's much harder (presumably) for th= e compiler to take a compile-time string and invoke the compiler on it, wit= hin the current scope as if it had been written text.

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

Not only that, once you get into wanting `constexpr` strings t= hat can be interpolated, you get into lots of issues. Do you really want a = feature 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 ab= out compilation and formal languages in general, it shouldn't be very h= ard for a compiler to deal with expressions within `F"{}"`.
=
The compiler already do that kind of stuff with parentheses. Compilers= are by nature recursive.

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.

--
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/3a738e91-f935-4d11-ab6b-771048b556d4= %40isocpp.org.
------=_Part_1372_1055808211.1518712406608-- ------=_Part_1371_343370368.1518712406607-- .