220 36870 <1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83@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: Sun, 11 Feb 2018 10:08:44 -0800 (PST) Lines: 307 Approved: news@gmane.org Message-ID: <1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83@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> <8e456af5-09c3-461d-8562-30df127e93af@isocpp.org> <28e80709-5ebb-44d2-b26d-22cafd681330@isocpp.org> <52b86f0a-b3b9-455f-9d4d-0f6b15192c90@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2489_1164935945.1518372525022" X-Trace: blaine.gmane.org 1518372425 9788 195.159.176.226 (11 Feb 2018 18:07:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Feb 2018 18:07:05 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLMNQLKAKGQE4Z2CKAI@isocpp.org Sun Feb 11 19:07:01 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 1ekw1R-000159-VZ for gclcip-std-proposals@m.gmane.org; Sun, 11 Feb 2018 19:06:42 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id g47sf8941169uad.14 for ; Sun, 11 Feb 2018 10:08:47 -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=nkkZ1rDtKCAA73A3N79GekEtz42Z92c2wA1rRXGbqu4=; b=iMMrK0rkYOpNA/wHaFa76BMM52+oV32LlBaZigSPVy4iImjEi5/e3BuGB7KWxci/iL 8cu00berrKsymAWUwGJVMMUUwMX7dj0iPLIK4vPzdWSD10PFqYLkTxSHKyGmyjs1D9c/ ch9oKX2jAAFM/3LCIcDUdDyKtFsjfbqR63ClJFJiLqe6sYhF4sGGdWADZQBkQZ+2tPCu w1XGvmCgMiYpMFtTHdc607RjVEknBXtmeLkbwVrCbHnojwRFLxo/1qQBsZ26MdExcum8 4+l2rsN05E6nymEeDrzRHmohJXz56dWhN8sosO9Ut7IzFsJf9oFOJJGYXHq2jrswF+PP JqUA== 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=nkkZ1rDtKCAA73A3N79GekEtz42Z92c2wA1rRXGbqu4=; b=mKjkGxjRBCG/qLyn4jjPI+dD3h39egzFXeSUS8feUhv+6YgxB6G9bDkatUEL0R3M1Q dOkVAe5qy2A7G6CqUgJYMQRYotwB/pV+N/G4VzN+nf/CR9m/mogpkpii9pyxK85top5W WAQvrI2U3W6IpMlG5zw9SAy+j4H6qFCYChufR/WYII7FBztbNCNbIo8Lzb+uSDsHwvDr qZmZqEDJz0KM4v8UKwSE2t3LtzqzggtDl3tbSRa9JL6WP0IhiwjMJL3ElYGmiRaB+Ecc 7tBU3miwMqpknY+Lc/gIk0afILm6hL8LOsOn73fTWTZZET6BeaGKbZB/aPyyc1vLHvTK 7fJw== 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=nkkZ1rDtKCAA73A3N79GekEtz42Z92c2wA1rRXGbqu4=; b=pzB19pqa7Hs/dXLdscwFOz9siE8gGVAw/+1/wzoCvD+xeCuMqT0uDZ3D8sf+y4d6CW FdIh2AgqgaGOh5CPMooGTjlrRV7UlxYNfPo3ijhssCDJTzqCIvXFrRdBoziGZEQ9L8BV 2CgFYjJ3+e8y/LWco+/FU/AU2mcKuJAz9n3+748OieDwE6303/Vs/eGCbwh6DEgEvk1P xrrhAdWY9FodyzwxyZGM/yly6l7PhriN1JMbx2Oe/9Gul4db52ttJEinLARFp3jzRnF+ eagaU3mdZT7qzxxOTYs/PUXJDIY2egKz+boKbjckl09zk6Izd/8W3h7akY2/J4Mf+rCf pAwg== X-Gm-Message-State: APf1xPCSIVw7MqSOOMN7+tYi/E2+CK2ZgD+7SV3ZOyz2ZESbSuiAjnzF sIiwTJL2pDCRZswwcU0q+5rkqg== X-Google-Smtp-Source: AH8x227VVKGCW4Qu07lVmfE9rWXrCsIBqhaqH1YhUv4k3J7tGoby4TFCXsUxkXxw0M0zmN0HsooFaQ== X-Received: by 10.176.85.139 with SMTP id v11mr2655441uaa.71.1518372527263; Sun, 11 Feb 2018 10:08:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.67.196 with SMTP id q187ls6031764vka.21.gmail; Sun, 11 Feb 2018 10:08:45 -0800 (PST) X-Received: by 10.31.128.137 with SMTP id b131mr819915vkd.7.1518372525604; Sun, 11 Feb 2018 10:08:45 -0800 (PST) In-Reply-To: <52b86f0a-b3b9-455f-9d4d-0f6b15192c90@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:36870 Archived-At: ------=_Part_2489_1164935945.1518372525022 Content-Type: multipart/alternative; boundary="----=_Part_2490_1052652035.1518372525022" ------=_Part_2490_1052652035.1518372525022 Content-Type: text/plain; charset="UTF-8" Your new idea is really no better than the old one. The problem comes back to the same point: you are conflating two fundamentally distinct operations: the operation to be applied to each string fragment, and the operation to be applied to aggregate the fragments into a whole. Your first idea involved the use of two UDL overloads, thereby tightly coupling the two operations. Your second idea only uses one UDL overload, but it still tightly couples the two operations by forcing all string fragments to use the "same type". Or more specifically, to use the same string fragment processed template: `std::string_literal`. In 99% of cases, you don't need to do character-by-character analysis of such literals. A simple array of characters will do. This is why the UDL definition syntax doesn't *force* you to process all literals by characters of a template parameter. It certainly gives you that option, but it is not forced on you. There is no reason why string interpolation should force this upon you. With my way, you can *choose* to process the fragments this way: template auto operator ""literal() {return std::string_literal{};} std::do_something(F"some string {variable}"literal); But you aren't *required* to. You can choose how you want to process those fragments. The 99% of cases that work just fine with `const char*`s or whatever don't have to deal with this `std::string_literal` type. The 1% of template metaprogramming heavy cases have this available as an option. Exceptional circumstances should be optional, not the default. I do not understand your fervent insistence on using UDLs to provide the aggregation function to be called, rather than explicitly calling an actual function. It doesn't even make sense conceptually. On a conceptual level, a UDL operation produces an object. But not all aggregation operations on an interpolated string will produce an "object"; I see no reason why I can't do this: std::output(std::cout, F"some string {variable}"); This just writes the individual members of the interpolated string to the given output stream. No object is being generated; I'm simply invoking a process. Something similar goes for your SQL database operation: db.exec(F"some sql stuff {var1} more sql {var2};"); No object needs to be created; you're just running a command. Using UDLs to invoke the aggregation operation is just the wrong concept. On Sunday, February 11, 2018 at 9:20:28 AM UTC-5, Marcin Jaczewski wrote: > > On Sunday, February 11, 2018 at 9:35:50 AM UTC+1, Nicol Bolas wrote: >> >> On Saturday, February 10, 2018 at 9:38:20 PM UTC-5, Marcin Jaczewski >> wrote: >>> >>> And then wat result will be of: >>> auto x = F"A {42} B"_z; >>> >>> If it work as pack expansion then it do not have meaning on its own. >>> >> >> You say that like it's a bad thing. Does `pack...` have meaning on its >> own? >> >> > You can use pack expansion only in specific places: > I know that. My point was that we already have grammatical constructs like that which only work in a limited number of places. What is wrong with making string interpolation work that way? The point of my idea is that it provides a sharp separation between the two >> fundamental operations of "string interpolation". There's the "convert a >> string literal into a bunch of smaller literals and variables" part. And >> there's the "do something with that bunch of smaller literals and >> variables." >> >> By making part 1 into a pack expansion-like construct, it forces you to >> make the way you want to process that expansion *explicit*. It also >> makes a clear distinction between a UDL used for normal purposes and the >> system used to process code. >> >> > But this work in this way in C# and JavaScript (and probably other > languages too), C# return final string (or interface that you can tweak > result a bit) and JS return fully processed object from tag function. > My approach mimic it. > C++ has many language features that do similar things from other languages but in different ways. Lambdas are pretty unique in C++, as are the way we handle variadic parameters and expansion (most languages make you index the variadic list; we allow you to write patterns and expand them in-situ). Indeed, every language has its own specific quirks and distinctions. I see no reason to exactly mimic other languages when we can make the mechanism so much more flexible than what you're proposing. Not unless it actually gains us something. You can't change return type based on `char*` value (this was what Marcel > used in his version), this would require `constexpr` arguments that > probably will be never added to language. > `constexpr` programming is not based on a 1:1 mapping between "type" and "value"; it's based on regular C++ programming principles. On using different *values* for those types; we're just doing it at compile time instead of runtime. That's why its much better than trying to use template metaprogramming. In short, you don't *need* it to work this way. Once we can actually create and manipulate strings at compile time, there's little point to using metaprogramming to process them. -- 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/1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83%40isocpp.org. ------=_Part_2490_1052652035.1518372525022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your new idea is really no better than the old one. The pr= oblem comes back to the same point: you are conflating two fundamentally di= stinct operations: the operation to be applied to each string fragment, and= the operation to be applied to aggregate the fragments into a whole.
Your first idea involved the use of two UDL overloads, thereby tightly co= upling the two operations. Your second idea only uses one UDL overload, but= it still tightly couples the two operations by forcing all string fragment= s to use the "same type". Or more specifically, to use the same s= tring fragment processed template: `std::string_literal`.

In 99% of = cases, you don't need to do character-by-character analysis of such lit= erals. A simple array of characters will do. This is why the UDL definition= syntax doesn't force you to process all literals by characters = of a template parameter. It certainly gives you that option, but it is not = forced on you.

There is no reason why string interpolation should fo= rce this upon you. With my way, you can choose to process the fragme= nts this way:

=
template <char= ...= chars>
auto operator ""literal() {<= /span>return std::string_literal<chars...>{};}

std::do_something(F"some string {variable}"literal);

Bu= t you aren't required to. You can choose how you want to process= those fragments. The 99% of cases that work just fine with `const char*`s = or whatever=20 don't have to deal with this `std::string_literal` type. The 1% of temp= late=20 metaprogramming heavy cases have this available as an option.

Except= ional circumstances should be optional, not the default.

I do not un= derstand your fervent insistence on using UDLs to provide the aggregation f= unction to be called, rather than explicitly calling an actual function. It= doesn't even make sense conceptually.

On a conceptual level, a = UDL operation produces an object. But not all aggregation operations on an = interpolated string will produce an "object"; I see no reason why= I can't do this:

std::output(std::cout, F"some string {variable}");

This just writes the individual members of the interpolated stri= ng to the given output stream. No object is being generated; I'm simply= invoking a process.

Something similar goes for your SQL database op= eration:

db= ..exec(F"some sql stuff {var1} more = sql {var2};");

No object needs to be created; you&#= 39;re just running a command.

Using UDLs to invoke the aggregation o= peration is just the wrong concept.

On Sunday, February 11, 2018 at = 9:20:28 AM UTC-5, Marcin Jaczewski wrote:
On Sunday, February 11, 2018 at 9:35:50 AM UTC+= 1, Nicol Bolas wrote:
On Saturday, February 10, 2018 at 9:38:20 PM UTC-5, Marcin Jaczewski wro= te:
And then w= at result will be of:
auto x =3D F<= span style=3D"color:#080">"A {42} B"_z;

If = it work as pack expansion then it do not have meaning on its own.
=

You say that like it's a bad thing. Does `p= ack...` have meaning on its own?


Y= ou can use pack expansion only in specific places:

I know that. My point was that we already have grammatical con= structs like that which only work in a limited number of places. What is wr= ong with making string interpolation work that way?

The point of my idea is t= hat it provides a sharp separation between the two fundamental operations o= f "string interpolation". There's the "convert a string = literal into a bunch of smaller literals and variables" part. And ther= e's the "do something with that bunch of smaller literals and vari= ables."

By making part 1 into a pack expansion-like construct, = it forces you to make the way you want to process that expansion explici= t. It also makes a clear distinction between a UDL used for normal purp= oses and the system used to process code.

<= div>=C2=A0
But this work in this way in C# and JavaScript (and probably = other languages too), C# return final string (or interface that you can twe= ak result a bit) and JS return fully processed object from tag function.My approach mimic it.

C++= has many language features that do similar things from other languages but= in different ways. Lambdas are pretty unique in C++, as are the way we han= dle variadic parameters and expansion (most languages make you index the va= riadic list; we allow you to write patterns and expand them in-situ). Indee= d, every language has its own specific quirks and distinctions. I see no re= ason to exactly mimic other languages when we can make the mechanism so muc= h more flexible than what you're proposing.

Not unless it actual= ly gains us something.

You can't change return type based on `cha= r*` value (this was what Marcel used in his version), this would require `c= onstexpr` arguments that probably will be never added to language.

`constexpr` programming is not based on a 1:1 = mapping between "type" and "value"; it's based on r= egular C++ programming principles. On using different values for tho= se types; we're just doing it at compile time instead of runtime. That&= #39;s why its much better than trying to use template metaprogramming.
<= br>In short, you don't need it to work this way. Once we can act= ually create and manipulate strings at compile time, there's little poi= nt to using metaprogramming to process them.

--
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/1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83= %40isocpp.org.
------=_Part_2490_1052652035.1518372525022-- ------=_Part_2489_1164935945.1518372525022-- .