220 36939 <2a035024-304f-45d6-ac03-ad13e7848b9e@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 22:02:35 -0800 (PST) Lines: 154 Approved: news@gmane.org Message-ID: <2a035024-304f-45d6-ac03-ad13e7848b9e@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> <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/mixed; boundary="----=_Part_2968_1348391206.1518760955956" X-Trace: blaine.gmane.org 1518760849 27775 195.159.176.226 (16 Feb 2018 06:00:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 06:00:49 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB7PHTHKAKGQEGAVE6GY@isocpp.org Fri Feb 16 07:00:45 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1emZ4T-0006EU-0v for gclcip-std-proposals@m.gmane.org; Fri, 16 Feb 2018 07:00:33 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id g17sf1233750uak.20 for ; Thu, 15 Feb 2018 22:02:39 -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=vg+z7e/IW2E4W2rig797xar0Okdq55qyU5/yyG0EJ3c=; b=PNahQUOqxg7DOzf8YOmPdbEuvzizPL36PCO/1016sN4TmhdRBhnWP002G4492weqIE e8xbvOAPGFJ08JVx50Om3IUMlWMkC5Bo9LjsOhx+z4TlmE08vhGgPNHesULKzuPn5Q8+ qBeqxTB011lhXJhqzRGG6ib5CuBrBr4y5uqZEmxbg//EZVlAgpQEsKYVk5hqkdTvn7bw daLr05JNY/i6fBcXu8sOCttUyWid5wCSsLATivnYKAg5ClmC4MbL9oyl8DT4taKqxnEy WhSY3ahMsdhYbWIYbuo/wMkVPzV1BmQQYJC3dw4F+BEvh6NRkGtHQRt+SswVEn17HhPy 2+NA== 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=vg+z7e/IW2E4W2rig797xar0Okdq55qyU5/yyG0EJ3c=; b=eX4IUBYtOw12tQqKq9zYPqV3iLaG3S6GOj23+NBr0sQaHocofPMn9gfyezUq/McC2R xxz5J38Rub0uXoyVog1IBRKy16gb+GFV7Iqe0uLy2Rb/BvVvWF6D3k6hUIM3NJtIx1/g Ho2y2AANvXKO3PSIesAXXe60zxWHsLi0t4ozZAAgPzajWmHDoL87/vU1XoZpNXha8+7P beOTOBx5D1LtjgnxgpDspBr4NrBUSJrQbEZEh+sPOlwFJeNN77+SnF0S4wA7TX4sdOIZ H4Wv1Y0JHkhmh9OpgWJXzS5D7vVSBst1AKbpQGKmMVj9uQxtp6ZxiOFEnhSFeyiODIcN ukcQ== 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=vg+z7e/IW2E4W2rig797xar0Okdq55qyU5/yyG0EJ3c=; b=TIh7DD/R4Ow1ufk3OT2htVp9/Jb43Dgnjr/lk+4rfXlr6qAP3sITJuQWbJCIl1uP3z rQswyAu/Phb36BFnOdOytuKDqJ7suWLEFINc59MogaEdqUJnvkywogxlFUuy+xJZhG4u OmMYx2RBCfXlWUE98q7SUE26VmqizWSZaTCANgj38iu3LTK/Y/aiqAffQrC+ZMfLmaGp Cf3lphRKLxtTpx9tHZMU5Z88Rd6mmKyDo7ZnsJW+SY751ctIHgfP9jx9P5WvhZNV+sq2 /7GBKYYRrPLytt3Mud6n8VRFXXCxfg4N24eHuEKbIvnshd88ELDGU3fzkPAPMH9JB3SY 3RqA== X-Gm-Message-State: APf1xPAG+tP6BexSJ6JZ5vc8D6VsdWzlGAsmLEnNBcxR8pQudH6J5/iK Mdk1Ajg/iBg/SVJinNlKRhDE9w== X-Google-Smtp-Source: AH8x2247FIH3sTTUt97VqRcoHS+m0RQTZQRNb3QWmq1PgkT9f27XG6n+BVSOS6Udjas+k73DfRKYQQ== X-Received: by 10.31.79.66 with SMTP id d63mr5204435vkb.47.1518760958569; Thu, 15 Feb 2018 22:02:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.131.146 with SMTP id f140ls690611vkd.14.gmail; Thu, 15 Feb 2018 22:02:37 -0800 (PST) X-Received: by 10.31.52.211 with SMTP id b202mr931601vka.9.1518760956695; Thu, 15 Feb 2018 22:02:36 -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:36939 Archived-At: ------=_Part_2968_1348391206.1518760955956 Content-Type: multipart/alternative; boundary="----=_Part_2969_465134462.1518760955956" ------=_Part_2969_465134462.1518760955956 Content-Type: text/plain; charset="UTF-8" On Thursday, February 15, 2018 at 11:22:31 PM UTC-5, Jake Arkinstall wrote: > > 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}"; > But that won't be equivalent to `F"{" + F"other" + F"}"`; string interpolation is not associative. Nor does it address more complex constexpr string manipulation, like removing characters, splicing different fragments of strings together, and so forth. And none of that changes the fact that macro expansion *already happened*, and those strings were not included. How do you make macro expansion happen after it has already happened? That's the question. .... 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. > We don't want to get locked into a design decision (using arbitrary expressions in interpolation) that prevents us from adding new features (constexpr string interpolation). That's why it's important to think about what might be *before* deciding on what has to happen now. Imagine if `constexpr` functions had been declared in C++11 such that it would be difficult or impossible to later for C++14 to come along and expand on them. Maybe they used non-standard syntax or something. Even if it were a workable design, it wouldn't be a good one because it wouldn't be easily extensible to features that we would reasonably find useful. If we decide later on that arbitrary expressions are more important than constexpr string interpolation, or if it's found that the two don't interfere as much as I think, then we can expand on that. But once arbitrary expressions are there, they're *there*, and there's no way to restrict them back to something more constexpr-able. -- 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/2a035024-304f-45d6-ac03-ad13e7848b9e%40isocpp.org. ------=_Part_2969_465134462.1518760955956 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, February 15, 2018 at 11:22:31 PM UTC-5, Jake = Arkinstall wrote:
I misread your example, but the comment holds if referring to get= ting the same outcome=C2=A0and still using concatenation - not havin= g the result being a string, by instead allowing concatenation of interpola= ted results:

F&qu= ot;this is my var: {var}" + F", and this is my other var: {otherv= ar}";

Equivalent to=

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

But that won't be equivalent to `F"{" + F"other= " + F"}"`; string interpolation is not associative. Nor does= it address more complex constexpr string manipulation, like removing chara= cters, splicing different fragments of strings together, and so forth.
<= br>And none of that changes the fact that macro expansion already happen= ed, and those strings were not included. How do you make macro expansio= n happen after it has already happened?

That's the question.
=
... or maybe with an extra element = if we opt not to go for the "the first, last, and every other e= lement, are always literals" approach.

So purely in the scope of concatenation of self-cont= ained interpolated expressions, we do have something to play with. I ce= rtainly 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 avoidanc= e. 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-handl= er 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 familiari= ty with the main proposal of just being able to handle the simplest form mi= ght be enough persuasion to extend it.

We = don't want to get locked into a design decision (using arbitrary expres= sions in interpolation) that prevents us from adding new features (constexp= r string interpolation). That's why it's important to think about w= hat might be before deciding on what has to happen now.

Imagi= ne if `constexpr` functions had been declared in C++11 such that it would b= e difficult or impossible to later for C++14 to come along and expand on th= em. Maybe they used non-standard syntax or something. Even if it were a wor= kable design, it wouldn't be a good one because it wouldn't be easi= ly extensible to features that we would reasonably find useful.

If= we decide later on that arbitrary expressions are more important than cons= texpr string interpolation, or if it's found that the two don't int= erfere as much as I think, then we can expand on that. But once arbitrary e= xpressions are there, they're there, and there's no way to r= estrict them back to something more constexpr-able.

--
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/2a035024-304f-45d6-ac03-ad13e7848b9e= %40isocpp.org.
------=_Part_2969_465134462.1518760955956-- ------=_Part_2968_1348391206.1518760955956-- .