220 36927 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 08:19:29 -0800 (PST) Lines: 156 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1366_242682078.1518711569246" X-Trace: blaine.gmane.org 1518711459 4359 195.159.176.226 (15 Feb 2018 16:17:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 15 Feb 2018 16:17:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBEXGS3KAKGQEXFOLXCQ@isocpp.org Thu Feb 15 17:17:35 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 1emMDt-0000ME-Sp for gclcip-std-proposals@m.gmane.org; Thu, 15 Feb 2018 17:17:26 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id y11sf107944vkd.11 for ; Thu, 15 Feb 2018 08:19: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: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=a7u6Xt76DLx2PCFQCaBR+ALuwUcPlvfBcwDsl7A+11E=; b=Rgpv51jHz+O0BMs0GR7zgOdEOfif37D5JISpno5Pik4cD/9+20ndp9TDnUmwV0Zq8d niLSZvFcAoxhnEtFw+XRFi/mzfpx+MmcwPOr5H6ERJOlco01HkeXtxE6VEEo6IV8TMTH 3DsEhfeOjlC9ZTOvH25AaxmdkWRS0GUgrpfyGvt1+TDhZ/BGpRjixFav87p0c5pDh57M 8LfF59nV4mwkz3qwApGyr1wTMmTai1Jfmp8MJs7CuXrMa+UpaSVxzvekDZtuVBiy29R1 0vwQnEASMcSc5+FrxZUrrm6jkxcVK3lnFq6y6yYEIN46IviutEoOrF7scHAX6t88k48h bTQA== 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=a7u6Xt76DLx2PCFQCaBR+ALuwUcPlvfBcwDsl7A+11E=; b=fzVI3S8pgosckDlDqqL+PAwV1Eu7ZzLdMNf8HYCxxPuI6AcB9PWl0wbN8chgOQ38Ql MhPj1+gDn5hsJDmMbwdNFRvlkQSmTk+NAgD+/IoDEX0NhffCyLoy2OnCYtSWv1mGGT2w pZ0neAz+bTzritJYhMtzhAgPm3tS/gedMjEndv11fOymgBRj2MGFVsJjwPd/D1Z/gH0F O9hINlCbLRE+5ZE21ubN8A01dkkCVwff1Fg1yFnu9/cNj3Zu4UFaLPAXEQuDCxO+NPOg 5qbZmB4UoBeGqgKXDDuLdKuP/Hhe9MCD0ySbU9hRf5rXBBbMcEfjFyLvYHd6HktA0SBm As7w== 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=a7u6Xt76DLx2PCFQCaBR+ALuwUcPlvfBcwDsl7A+11E=; b=R+sJ/35PRJWLC3Tlalq/ccncNqZHmgDzxzj4bfGcScV+lgO1krj0LkOBcUWEeO84hD 003fHSHAAJpQt/xERnSH0axU39IW8HItraD9jVIAA4sMn33sQAHONJSAbbfjNwjgJN0Q kpUg8x+zXPSDhb5EVxe5ZMbfYPo3U9tmYGw2+oJ5bl0DnnV2ZdOkW8Epf/1wkDrCOvL7 4bT1cqHX+phYjqXqGVXUOtGOKD9EgTq4jikVB79yaJtXPkbmBGJCU9MZL9oDrNbDRHhD ZuFvP22dI+sI5NPK9e/5tKWt+3ST5WysX5H2sZi8REpCDQMDUVtC/cw8OBCbxH+0JZpV GBQQ== X-Gm-Message-State: APf1xPAPQTXj0aiiNIG4LDBBc9W3vyzPRliDE+/9m07pBsXZBO3HFngY iHAFCX24K/t3IrGUvg9Ty1d97g== X-Google-Smtp-Source: AH8x225toXZAeNivDGqi0eIU5QRIqFJgpI0zfv8+9TVNB/BvvMFJ7sRL+pvDs1M+vuExLAYwKoVjrw== X-Received: by 10.159.46.25 with SMTP id t25mr4192121uaj.52.1518711571805; Thu, 15 Feb 2018 08:19:31 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.191.147 with SMTP id p141ls105337vkf.19.gmail; Thu, 15 Feb 2018 08:19:30 -0800 (PST) X-Received: by 10.31.171.81 with SMTP id u78mr429996vke.8.1518711569999; Thu, 15 Feb 2018 08:19:29 -0800 (PST) In-Reply-To: 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:36927 Archived-At: ------=_Part_1366_242682078.1518711569246 Content-Type: multipart/alternative; boundary="----=_Part_1367_2098218891.1518711569246" ------=_Part_1367_2098218891.1518711569246 Content-Type: text/plain; charset="UTF-8" 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 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 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 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 the compiler to take 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 as 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 able to synthesize arbitrary expressions and have someone insinuate them into their code at compile time? Or... maybe you do? -- 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 email 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/c74fcb96-ed06-4360-bedf-e902b000b13b%40isocpp.org. ------=_Part_1367_2098218891.1518711569246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, 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:
Taking a literal (or possibly constexpr string?)

I was wondering whether it makes sense to even describe these t= hings as literals, given that they aren't literal and given that they a= ren't intended to actually be stored in memory in any way.
<= /blockquote>

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

But in terms of constexpr strings, I guess these things themselve= s can be built up by other methods - I'm not sure if this makes sense i= n compilation, though; I'm under the impression that the expression its= elf would likely need to be processed before the constexpr methods themselv= es 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 sen= se in 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 goi= ng to concatenate strings, but it doesn't have to. C++ sometimes= defines concepts with names that are similar to other language features, b= ut in a more open and freeform way. Lambdas for example don't have lexi= cal scoping in C++ unless you explicitly ask for them, whereas most languag= es give it to you as a matter of course.

(o= r possibly arbitrary expressions?)

This wouldn't be so muc= h of a problem, because those expressions (other than their declarations) d= on'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 t= hat 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 varia= ble in scope that matches it. It's much harder (presumably) for the com= piler to take a compile-time string and invoke the compiler on it, within t= he 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 ca= n't imagine it's as easy as just finding a variable with that name.=

Not only that, once you get into wanting `constexpr` strings that c= an be interpolated, you get into lots of issues. Do you really want a featu= re where you're able to synthesize arbitrary expressions and have someo= ne insinuate them into their code at compile time?

Or... maybe you d= o?

--
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/c74fcb96-ed06-4360-bedf-e902b000b13b= %40isocpp.org.
------=_Part_1367_2098218891.1518711569246-- ------=_Part_1366_242682078.1518711569246-- .