220 36938 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Fri, 16 Feb 2018 04:22:28 +0000 Lines: 260 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> <138fc3e9-8538-4ae0-8912-1a1e3d003c5f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d43e63aef5405654cb185" X-Trace: blaine.gmane.org 1518754847 25398 195.159.176.226 (16 Feb 2018 04:20:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 04:20:47 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBBNZTHKAKGQEDRLY7MI@isocpp.org Fri Feb 16 05:20:42 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emXVZ-0005EQ-G2 for gclcip-std-proposals@m.gmane.org; Fri, 16 Feb 2018 05:20:25 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id 16sf970446oin.13 for ; Thu, 15 Feb 2018 20:22:31 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1518754951; cv=pass; d=google.com; s=arc-20160816; b=z3IvPC1+Lh8ESb+pAIBFUMb1dry48EV4TM97ZLJ9VTQdNbUOsxk0yMPglkNr3GdPfu ysh1m4TPrBforQHDs4wnj/J2w+CXGXWINPptzMMytSHR9k9AWoBYpqebnpbDM+Ef+t4n uQ3uX/MpYLe1KdIOadqYsOEDu4qa10lYSorrOfJRT6GKJewAhPlvVfVwScEZ8ukTJYjg BRpwMYvTvbjkojKO6w9fX9JrMpU9JL0hcvwPwOjULjrwQTRlYaUNViSPj9gDYdTcTHH+ lbuwkLmnPL3d8WFlb8CMQJYAT3iqfCItAk/rLMPs0XVzYIPZawEVIQSh8Tpe+uWnO9xU VNnw== 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:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=Snb2Chboot5UsNfppqNmFQDE6JR0cGboCYdkYAzLCMI=; b=kThPnWiiLZKqevr5cGK4vQP3LFV5KWbfvVTmc427SYw7v1SgTFNwt+Dj9e+N79V4G5 3MPj1iXvjXK5xKGo4OcSJAT4GEhLv6eRP4G+wQrabhfaphkuw020IMa4+Pk3Kz000nmj VWIQYej+IywrJXkMcMI9XXAlXo01ycyWb8wngGOkOhRdMAdy3LXSKmBDP+Mn1/YLhmW0 LibFfl/BWijr/b7sIXCgBVcCkkgl5Glr8L+RaOyXGZQhu7TARKW+3DIARtdwgyV6Gp9G r7sVlTw0gfK9Q3Z3xA/QhLnRbG0q30SNmGXqWOawGrS8WfvbdsOAf8OzEt0HSBPDLm85 Fq6w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ONVce+kd; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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 :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=Snb2Chboot5UsNfppqNmFQDE6JR0cGboCYdkYAzLCMI=; b=Jx83beENy1zSPv/PegMIlbVhDkFeCo1J+c2bcj/Ie0cn0zHDfCXiqkVSwkMTPH9tYA VH4BGceSqLAaN9FIRbhOKtx5dibQPX2k+83hpIeMhz1LWOrzClc1ZFyDhjGJQJ1rQauC BNHKxphyGNQybEqKqSQNbmcVWvHaW17VL3RsBsuYJnZLD0IC/YpoobAwr6W644+ei6r4 jlF1zI8mjqykkTr7KbKIUOduNisGi8Yg5QK26fcRs9KBKsRr2qJDWpNsHRZ1bB1DzYxa BUYQWQEpBclJvETYENsGqY4vplKne7q3lhbKBZFJdtqtOHLkAWIe+nOKagtVm1lJA37e iv/w== 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: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=Snb2Chboot5UsNfppqNmFQDE6JR0cGboCYdkYAzLCMI=; b=Z4jRJ7mTwdCMIOP4LvxpyFwPioD2d0bRhXIblVfQwupUtx67fEZUUps/bE6Eam/3HK 6EH3P4qnVZ1SSxT1i0CN7+yX1o3okTaU6E6EvKl9YWO7kesaOpWwhss6y4DQacQhb6iJ 7VYCGaHka4Rbh8w4ZkErmrqfu9XoiXJvTVcQeWiKK13EaqBrexXZjvUU7zkXcYw8QSfT jZ5ZVI8qdiOCSbWxR3KvJk13kr0A2YTurouJQXXX/+diT+lSZEe41YpY7P/EaB8+kGRc nxdaxrfrf53DwMpXJo++nYUuhCcMl2r1WO1fojrI4ntC7BuEQoFD7BdAJ06C5SgK4m7M 4Aiw== X-Gm-Message-State: APf1xPDUIs7KAPEEkm4vt/FJSY1e7oljQUnxNeFjTO4sQu89Arknopxo qiL5YTVXbKYoURga3aZML4aA7w== X-Google-Smtp-Source: AH8x227euHzc1OmmDBqQYg1kSqIP+8vI8n0Tk5vABf0G1orKjkqHjmIp1+iiD2NyNafkhfMX1+pqbA== X-Received: by 10.157.0.40 with SMTP id 37mr2470049ota.100.1518754950907; Thu, 15 Feb 2018 20:22:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.17.9 with SMTP id 9ls186961oir.21.gmail; Thu, 15 Feb 2018 20:22:29 -0800 (PST) X-Received: by 10.202.58.8 with SMTP id h8mr3215598oia.88.1518754949514; Thu, 15 Feb 2018 20:22:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518754949; cv=none; d=google.com; s=arc-20160816; b=udJUtARZ9E+8bXwg7n/4XpKKHz/tMzYjZ00BxFya0Vnk25iDW500qTnz9Gzb8zP9HQ LmoQvMfGno6n4gbIAHpDHwI+jEhDJBFzSH8xYmyQl8HQbRKLuocnb7H3HOr/ETEK5yvN E/UqULtCTitDTYZhxSfTok3lPZOcEZwAhN95i4JOFo+t472qw6ZS6ub38cCQLIe41bYi G+G7WHdg9k2QD3NlG3xNUGIXNIEhh1xGm0yR5Ib8i5Yqw1AJeckbgghrQPyE+8DW4Dvq kbgw44om7mx9Cysmn4kgjtcrn7tZcwRPFiPYdMkADOAm8hq/6NZIcXR9/p7TQMzuBEnC yzkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=cz9Y9nPT5XE9QZm76krT6MOaML/V4E7C/3qCY5gHcrw=; b=EwoF50fTbabIexdQ2dWO/i/xd2yVbIzRC2QmKMYsdvjP1+90XY1Nb14koHv58seDDw CSnEfigK8zd6fC2rLx2fKonDw85FgW1TVDVCgrLdHwGexzey7fTTa1Ozw029rebkgKUw M/OUvESd1mc4axXHRMDjgnkoRSpJrE8PgaItnq6bK/1ltTtFVIO3bIGxtfPj0Jo03Oss aScuVET1IDbiz3yDoXYiCUs/PG3ZyCzjdUJYHa72saWjzBZ2fVtlbY0Qnw+O5sT2ilAi hZS9+57BSyKZmDUXEpoEnAeUbvRukQz7BVgzpSi5XoVqXQJzQunQ+NTl2my+/tJB+tsh lGEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ONVce+kd; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id j20sor1930615oii.254.2018.02.15.20.22.29 for (Google Transport Security); Thu, 15 Feb 2018 20:22:29 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.93.9 with SMTP id r9mr3554795oib.105.1518754948901; Thu, 15 Feb 2018 20:22:28 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Thu, 15 Feb 2018 20:22:28 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Thu, 15 Feb 2018 20:22:28 -0800 (PST) In-Reply-To: <138fc3e9-8538-4ae0-8912-1a1e3d003c5f@isocpp.org> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ONVce+kd; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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:36938 Archived-At: --001a113d43e63aef5405654cb185 Content-Type: text/plain; charset="UTF-8" I misread your example, but the comment holds if referring to getting the same *outcome* and still using concatenation - not having the result being a string, by instead allowing concatenation of interpolated results: F"this is my var: {var}" + F", and this is my other var: {othervar}"; Equivalent to F"this is my var: {var}, and this is my other var: {othervar}"; .... or maybe with an extra element if we opt *not* to go for the "the first, last, and every other element, are always literals" approach. So purely in the scope of concatenation of *self-contained* interpolated expressions, we do have something to play with. I certainly didn't mean arbitrary expressions, or handling of *incomplete* interpolated strings concatenated into complete interpolated strings. That stuff would be nice, but will need some very careful obstacle avoidance. If the order these things get done is implementation-defined (that, I do not know, but will aim to find out), then the more flexibility we aim for, the higher the chances that there exists a compiler for which the proposal is incompatible and their devs will push for a rejection. *If it isn't* going to go down well, losing constexpr manipulation of the input to the interpolation-handler is a shame but not the end of the world. We may find a solution and add it as a secondary proposal at a later date - the community having familiarity with the main proposal of just being able to handle the simplest form might be enough persuasion to extend it. On 16 Feb 2018 03:17, "Nicol Bolas" wrote: On Thursday, February 15, 2018 at 9:52:50 PM UTC-5, Jake Arkinstall wrote: > On 16 Feb 2018 01:32, "Nicol Bolas" wrote: > > My feeling is that you have to pick one or the other: you either allow > arbitrary expressions or you allow constexpr string 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. > > > I agree here. We can get something along the lines of an addition operator > that acts in the same way as concatenation - so we could have your example > by performing the interpolation and concatenating the results, > .... I don't understand what you mean by that. Remember: string interpolation (in this design) doesn't "concatenate" anything. Only the function call performs that operation. And in my example, `my_func` returns a single string, not multiple strings. It's not clear how what you're talking about solves the problem of using arbitrary expressions. You cannot tell at the time macro expansion happens whether a particular string literal will undergo string interpolation. For example: constexpr constexpr_string my_func() {return "bar";} constexpr auto foo = "text {"cs + my_func() + "} moar text"cs; std::concat( foo); Here, none of the individual literals constitute a whole string to be interpolated. Only after concatenating the literals into a constexpr string can you get interpolation working. but in terms of e.g. allowing some constexpr string replacement, or other > more advanced string processing, I think it just adds more implementation > complexity and it could lead to some pretty dodgy practices (though it > would be a code obfuscator's goldmine). > Whether it happens or not isn't really my concern at present. I'd like it to happen, but that's contingent on how constexpr strings work out. What I'm concerned about is design decisions that make it *impossible* to ever go this route. And it's hard to see how allowing arbitrary expressions would not make it impossible. If you limit it to just variable names, then it comes back into the realm of the possible. It also minimizes the "pretty dodgy practices" you could pull off with it. -- 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/138fc3e9-8538-4ae0- 8912-1a1e3d003c5f%40isocpp.org .. -- 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/CAC%2B0CCNGuh4ihhh9c%2BwO9M_RCRovOOeMasUqfdYb0sCPVJx10Q%40mail.gmail.com. --001a113d43e63aef5405654cb185 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I misread your example, but the comment holds if ref= erring to getting the same outcome=C2=A0and still using concatenatio= n - not having the result being a string, by instead allowing concatenation= of interpolated results:

F"this is my var: {var}" + F", and this is my other var: {= othervar}";

Equival= ent to

F"this is my= var: {var}, and this is my other var: {othervar}";

... or maybe with an extra element if we o= pt not to go for the "the first, last, and every other element,= are always literals" approach.

So purely in the scope of concatenation of self-contained interpolated expressions, we do have something to play with. I certainly= didn't mean arbitrary expressions, or handling of incomplete in= terpolated strings concatenated into complete interpolated strings. That st= uff would be nice, but will need some very careful obstacle avoidance. If t= he order these things get done is implementation-defined (that, I do not kn= ow, but will aim to find out), then the more flexibility we aim for, the hi= gher the chances that there exists a compiler for which the proposal is inc= ompatible and their devs will push for a rejection.
=
If it isn't going to go down well, l= osing constexpr manipulation of the input to the interpolation-handler is a= shame but not the end of the world. We may find a solution and add it as a= secondary proposal at a later date - the community having familiarity with= the main proposal of just being able to handle the simplest form might be = enough persuasion to extend it.

On 16 Feb 2018 03:17, &q= uot;Nicol Bolas" <jmckesson@= gmail.com> wrote:
<= div dir=3D"ltr">On Thursday, February 15, 2018 at 9:52:50 PM UTC-5, Jake Ar= kinstall wrote:
On 16= Feb 2018 01:32, "Nicol Bolas" <jmck...@gm= ail.com> wrote:
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.=

I agree here. We can get something along the lines of an addition= operator that acts in the same way as concatenation - so we could have you= r example by performing the interpolation and concatenating the results,

... I don't understand what you me= an by that. Remember: string interpolation (in this design) doesn't &qu= ot;concatenate" anything. Only the function call performs that operati= on. And in my example, `my_func` returns a single string, not multiple stri= ngs.

It's not clear how what you're talking about solves the= problem of using arbitrary expressions. You cannot tell at the time macro = expansion happens whether a particular string literal will undergo string i= nterpolation. For example:

conste= xpr constexpr_string my_func() {= return "bar";}

constexpr auto foo =3D "text {"cs + my_func()<= /span> + "} moar text"cs;

std::concat(<<= span style=3D"color:#000" class=3D"m_1374652734628771457styled-by-prettify"= >insert interpolation syntax> foo);

Here, none of the individual literals constitute a whol= e string to be interpolated. Only after concatenating the literals into a c= onstexpr string can you get interpolation working.

=
but in terms of e.g. allowing some constexpr string repla= cement, or other more advanced string processing, I think it just adds more= implementation complexity and it could lead to some pretty dodgy practices= (though it would be a code obfuscator's goldmine).

Whether it happens or not isn't really my concern a= t present. I'd like it to happen, but that's contingent on how cons= texpr strings work out.

What I'm concerned about is design decis= ions that make it impossible to ever go this route. And it's har= d to see how allowing arbitrary expressions would not make it impossible. I= f you limit it to just variable names, then it comes back into the realm of= the possible.

It also minimizes the "pretty dodgy practices&qu= ot; you could pull off with it.

--
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-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/138f= c3e9-8538-4ae0-8912-1a1e3d003c5f%40isocpp.org.

--
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/CAC%2B0CCNGuh= 4ihhh9c%2BwO9M_RCRovOOeMasUqfdYb0sCPVJx10Q%40mail.gmail.com.
--001a113d43e63aef5405654cb185-- .