220 36879 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Mon, 12 Feb 2018 14:38:47 +0000 Lines: 691 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> <8e456af5-09c3-461d-8562-30df127e93af@isocpp.org> <28e80709-5ebb-44d2-b26d-22cafd681330@isocpp.org> <52b86f0a-b3b9-455f-9d4d-0f6b15192c90@isocpp.org> <1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83@isocpp.org> <750ecf62-9637-40f4-8585-e3be2780fb46@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a11c022f001c410056504d601" X-Trace: blaine.gmane.org 1518446224 7762 195.159.176.226 (12 Feb 2018 14:37:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 14:37:04 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRB6ONQ3KAKGQE2LBRINA@isocpp.org Mon Feb 12 15:37:00 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 1elFDo-0000m8-Mf for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 15:36:45 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id l66sf7602927oih.23 for ; Mon, 12 Feb 2018 06:38:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1518446330; cv=pass; d=google.com; s=arc-20160816; b=SOiAztUfFbxkFImF8gPjUsrGLKW0PM0wFn0osiWkl4JotCdXyBbKMVcYXibDJIuOlo ZdejtR2CszK2rEAJuwv4GtPnTbcuPsQ7Krr58JKittBUQxUlWQQQSlN6azj8qa+Li+1X tksQ3tp+jNI2nBhVtVu4RuoNA1L7L1a/uONa3N6JhhtKXRjgrALvvA3h8qbmYOf7Akje V5bN0DXfpA24SWAJbpcPucHBITMCwAzZ8CVzv+pOMud504mr9NTmkbNBYhDRfHjydq7p vh4k/TXTyTnbbQVEBUoAamtl1nReItiRASjGYvR7n+daEZDi+iEb4synrEcIdJFfxBAH mBcA== 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=9TBd/sS77k+M6y1Zj/qc1C+qGJ44sa305fYfdFJlvMs=; b=LEiHd7QC9GNC3vhFXHkSdDQ6IA1HoLsfExoHz4Bo1vTCdac3Z48lc7ZRSHUqwg4VwI uk2qOg6R02mgotAds8tzc6vgfrd92cax12IjwKxI5dHWaFu2U/IuW48D2xPzzKUQ4R6d UCCZu7WZ3S8SBWPfCpzOZJ9ArcpctgGlgZEqhrW5Nt4iLVT5AzmMw/jfyYL+ngvP99sr Bgu06GiXg5xr3ysfLGiYxtVDL5v8LQvAQ0cfucDDmZ5H3do1Ty2eBLKRkoEocw0OMJd8 j/gaTjbWRPXQq0KOTArJvN9va9PEUnmw0j8xO+7y7LYG9a4RseMEkBQSo/jpTq7TntzB 6JRg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cdUPunbd; 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=9TBd/sS77k+M6y1Zj/qc1C+qGJ44sa305fYfdFJlvMs=; b=MJdc9BT98RVPRH0fq9Hi4rLIIRkjBJjQTRqYTnlU9TDvcIDxVo1LhYqLE9saoBGipe K03yCwNdVDfJLntJvSY0OL6MlnpEQYBt/3dWcW8soE0En/GYIa+cwbvNh5G6LNC9JZCN pIpKPGPr+HxpgDDo63uLJHl0Ttv/NHfMZPo+EfN2cOjzlaLb5T3qIogdDHw0F5p3ineM jGpRBx8aQBAiaG/a4hGk0M5OtmbgdQBcB+F20ozUFZOofMCO1gaX1qcLknKGLsa6lAvc Yrh1q8mFbcpPhNmFHrjSznmzTUa+dMiuin5zAV/i95an5xoA2SELNKbfOhBnWukimZKS l6Ng== 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=9TBd/sS77k+M6y1Zj/qc1C+qGJ44sa305fYfdFJlvMs=; b=d1cu8WSS5BrYrQVMhO+ieDnYNTNgrdGt5stnVyqBmDhfTe31H72/YPZ94M88JODZpe uCLSAp0BkM04jT0PxuYDY2UZqG0saOCzheGdgGWo3LFg+y2BvRBq8o2roNtAOlXWMEhn tq64DQ+uTsWQqV4u2WTo88PnrOnm804T/X7vkCNTdz3wAEZq1KP9ZqiCknmn7bd4Q9CB Kro9QC8Ui8yHEyZjdDOMDuHRcyUab0Ht3PoU+jTu+MQzNNP4A3DBlvrZpg1X8sV5dOgx T2n9Tj5rP6AE0GxzvShzWoRAKAY94jL3wTTbLmlkXF1Q0maVModjZC+MdFQZ9CaHvp+x PVEQ== X-Gm-Message-State: APf1xPCRkwdKWn6IASOZouLonMPo9a4q9hrJ/dJYnud96bG8KvfV5jbG rJjyiy+xLnxWkcYq1UCz6/rFsQ== X-Google-Smtp-Source: AH8x227KkQ9DaKBp2g9veyn9KIEwwdwtOUtehvhdDe92iNvmDg+AbSgOH8SnDZElfecr/zkjbOS0MQ== X-Received: by 10.202.83.13 with SMTP id h13mr6603687oib.121.1518446330174; Mon, 12 Feb 2018 06:38:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.44.249 with SMTP id e54ls4762965otd.16.gmail; Mon, 12 Feb 2018 06:38:48 -0800 (PST) X-Received: by 10.157.32.13 with SMTP id n13mr8772250ota.35.1518446328839; Mon, 12 Feb 2018 06:38:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518446328; cv=none; d=google.com; s=arc-20160816; b=dl+/ih1RRFcbHFciXKT4dHVBC+Dc8cdsrjEz5jy9+ofoi/+GF5+JLzfdYMgEFuLqCs p39DLEBfK1eo5tQQ9VFohcMvRHjqtiPAhxzTxPw/WGmfNw1XegDJ5ZvjSXsBiuPrKrqv ZRRCR4pAU5HI4iAt+g1K+ZSosk6bLJvW4zWCIdsU4oVIkXGeAfH2vMnIUZQYmXnp4stL ZMXxKbtCh1828HbkOKI8L1ywG4lxQKRXlAjyMdFuYAwhmY+FHrQmEwL+lzOrO6dMMdPl 4qWXhqSPOmsslDSghArylPH2Dqew6rlpDxYCKLEbbZbKCTbwE9bU4KRNOWRw4nr64mNS CIkg== 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=tYD++UV+UpK+0fGX73xor2z6Hb8vzonZ2Cmw0VRd4eU=; b=vEAlfaRJLKZ7TT1WY8j+2UXBtf8AbWGAoPQY+Tk1fAXvOQgCFcZgLfcAbvBFixYfU2 KEhYOWOY/hfgs+53aTrhIvIOi+48fKYKVGyFg4j02zQR4KJEkLG46vLPQMylq7pE7i/R tw568+o7WXNwm6b2dcim2ZjRFqa9eWiut2VFpIEl6PajjMQjgaNMvm2NR/BPFzTgS7+n aIwIVLL5O5mvHbdhqNqJqCliJ0VnVwiCD43nrf7dKbeLInV1jowwYx/R000zmbHzLMPM b/kE2dIwr3kVtfAt3YrGJInoQPuZ0tXZ9QihhbJ7FYFVlpMQjPv9Ral6VJNW0dZLn/4r SOdQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cdUPunbd; 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 w42sor3796026otw.60.2018.02.12.06.38.48 for (Google Transport Security); Mon, 12 Feb 2018 06:38:48 -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.157.60.51 with SMTP id q48mr8508911otc.288.1518446328266; Mon, 12 Feb 2018 06:38:48 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Mon, 12 Feb 2018 06:38:47 -0800 (PST) Original-Received: by 10.168.151.129 with HTTP; Mon, 12 Feb 2018 06:38:47 -0800 (PST) In-Reply-To: <750ecf62-9637-40f4-8585-e3be2780fb46@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=cdUPunbd; 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:36879 Archived-At: --001a11c022f001c410056504d601 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is recursion a reasonable request in the proposal too? I actually can't think of WHY one would want it, but it might be worth a discussion for completeness. Nicol, what are your thoughts on Florian's suggestion? In the interest of grounding ourselves (although I'm getting quite excited here), does anybody from the compiler community have any input as to any stumbling blocks in the implementation of this? On 12 Feb 2018 10:17, wrote: Let me suggest something close to Nicol's solution, but not quite. The F"" operator returns a special type that could be like a simple tuple (let's name it std::string_processing for now). Then the user can use it directly into its own functions. auto column =3D "col"s; auto table =3D "tab"sv; auto req =3D sql(F"select {column} from {table};"); // would be equivalent to: auto req =3D sql(std::string_processing("select ", column, " from ", table, ";")); Now, if we want, we could also support UDL (but not mandatory) by allowing to call UDL on the std::string_processing: auto column =3D "col"s; auto table =3D "tab"sv; auto req =3D F"select {column} from {table};"_sql; // would be equivalent to: auto req =3D operator ""_sql (std::string_processing("select ", column, " from ", table, ";")); Now let's have some examples of it could be: Simple string concatenation would be simple auto concatenated =3D F"{str1}{str2}{str3}"s; // converted into an efficient concatenation of the 3 strings We could print it into an iostream if we want (but would be here only for convenience on legacy code) std::cout << F"{str1}{str2}\n"; // equivalent to: std::cout << str1 << str2 << "\n"; It could be implicitly convertible to a std::string (only if variables are implicitly convertible to std::string) std::string concatenated =3D F"{str1}{str2}"; (No example with FMT as I don't know how it works, but I don't see any reason for it not to be compatible with FMT.) And this would be constexpr-able. Now, formatting would require a bit more elaborated type that could store formatting information. But in the end, only the user will know what to do with it. However, I would prefer *not* to embed formatting in such a type, just to keep it simple. And use a library based solution when I really need formatting. It has all the advantages of Nicol's solution, while being more versatile. Florian Le dimanche 11 f=C3=A9vrier 2018 19:08:45 UTC+1, Nicol Bolas a =C3=A9crit : > > Your new idea is really no better than the old one. The problem comes bac= k > 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, b= ut > 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 actu= al > 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 =3D 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 lik= e > 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 "conv= ert >>> 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 th= e >>> 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 language= s > but in different ways. Lambdas are pretty unique in C++, as are the way w= e > handle variadic parameters and expansion (most languages make you index t= he > variadic list; we allow you to write patterns and expand them in-situ). > Indeed, every language has its own specific quirks and distinctions. I se= e > 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 templat= e > 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/750ecf62-9637-40f4- 8585-e3be2780fb46%40isocpp.org .. --=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/CAC%2B0CCOV7Qf21J-MBpdggkkrNt8Hs2dN03o52F0s-QXY6= f%3Dcbw%40mail.gmail.com. --001a11c022f001c410056504d601 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is recursion a reasonable request in th= e proposal too? I actually can't think of WHY one would want it, but it= might be worth a discussion for completeness.

<= /div>Nicol, what are your thoughts on Florian's suggestion?

In the interest of grounding ourselves (a= lthough I'm getting quite excited here), does anybody from the compiler= community have any input as to any stumbling blocks in the implementation = of this?


On 12 Feb 2018 10:17, <florian.csdt@gmail.com> wrote:
Let me suggest something close to Nico= l's solution, but not quite.

The F"" operator returns = a special type that could be like a simple tuple (let's name it std::st= ring_processing for now).

Then the user can use it directly into its= own functions.


auto= column =3D "col"s;<= /span>
auto table =3D &qu= ot;tab"sv;
auto req =3D sql(F"select {column} f= rom {table};");

// would be equivale= nt to:
auto req =3D sql(std::string_processing<const char[8]&, std::string&, cons= t char[7]&, std= ::string_view&, const char[2]&>("s= elect ", column, " f= rom ", table, ";&q= uot;));

Now, if we want,= we could also support UDL (but not mandatory) by allowing to call UDL on t= he std::string_processing:

auto column =3D "col"s;
auto table =3D "tab"sv;
auto= req =3D F"select {column} from {table};&qu= ot;_sql;

// would be equivalent = to:
auto req =3D <= span style=3D"color:#008" class=3D"m_5802088551998586929styled-by-prettify"= >operator ""_sql (st= d::string_processing<const = char[8]&, std::string&, const char= [7]&, std::string= _view&, const char<= span style=3D"color:#660" class=3D"m_5802088551998586929styled-by-prettify"= >[2]&>("select ", column, " from ",= table, ";"));
=

Now let's have some examples of it could = be:

Simple string concatenation would be simple
auto concatenated =3D F= "{str1}{str2}{str3}"s;
/= / converted into an efficient concatenation of the 3 strings

We could print it into an iostream if we want (= but would be here only for convenience on legacy code)
std::cout << F<= /span>"{str1}{str2}\n";
// equi= valent to:
std::cout <<= str1 << str2 << <= span style=3D"color:#080" class=3D"m_5802088551998586929styled-by-prettify"= >"\n";

It coul= d be implicitly convertible to a std::string (only if variables are implici= tly convertible to std::string)
std::string concatenated =3D F"{str1}{str2}";

(No example with FMT as I don't know how it works, but I don'= t see any reason for it not to be compatible with FMT.)

And this wou= ld be constexpr-able.

Now, formatting would require a bit more elabo= rated type that could store formatting information.
But in the end, only= the user will know what to do with it.
However, I would prefer not to embed formatting in such a type, just to keep it simple. And use a li= brary based solution when I really need formatting.

It has all the a= dvantages of Nicol's solution, while being more versatile.

Flori= an


Le dimanche 11 f=C3=A9vrier 2018 19:08= :45 UTC+1, Nicol Bolas a =C3=A9crit=C2=A0:
Your new idea is really no better than the old one.= The problem comes back to the same point: you are conflating two fundament= ally distinct operations: the operation to be applied to each string fragme= nt, and the operation to be applied to aggregate the fragments into a whole= ..

Your first idea involved the use of two UDL overloads, thereby tig= htly coupling the two operations. Your second idea only uses one UDL overlo= ad, but it still tightly couples the two operations by forcing all string f= ragments 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 s= uch literals. A simple array of characters will do. This is why the UDL def= inition syntax doesn't force you to process all literals by char= acters of a template parameter. It certainly gives you that option, but it = is not forced on you.

There is no reason why string interpolation sh= ould force this upon you. With my way, you can choose to process the= fragments this way:

<= div>template <= /span><char= ... cha= rs><= br>auto= operator ""literal() {return std::string_literal<chars...>{};}
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 w= ork 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,<= span style=3D"color:#000"> F"some st= ring {variable}");

This just writes the individual members of the interpolated str= ing to the given output stream. No object is being generated; I'm simpl= y invoking a process.

Something similar goes for your SQL database o= peration:

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

No object needs to be created; you're just running a c= ommand.

Using UDLs to invoke the aggregation operation is just the w= rong concept.

On Sunday, February 11, 2018 at 9:20:28 AM UTC-5, Marc= in 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 =3D F&= quot;A {42} B"_z;

If it work as pack expansion= then it do not have meaning on its own.
<= br>You say that like it's a bad thing. Does `pack...` have meaning on i= ts 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 o= nly work in a limited number of places. What is wrong with making string in= terpolation work that way?

The point of my idea is that it provides a sharp separa= tion between the two fundamental operations of "string interpolation&q= uot;. There's the "convert a string literal into a bunch of smalle= r 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 d= istinction between a UDL used for normal purposes and the system used to pr= ocess code.

=C2=A0
But this work in= this way in C# and JavaScript (and probably other languages too), C# retur= n 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 th= at do similar things from other languages but in different ways. Lambdas ar= e pretty unique in C++, as are the way we handle variadic parameters and ex= pansion (most languages make you index the variadic list; we allow you to w= rite patterns and expand them in-situ). Indeed, every language has its own = specific quirks and distinctions. I see no reason to exactly mimic other la= nguages when we can make the mechanism so much more flexible than what you&= #39;re proposing.

Not unless it actually gains us something.
You ca= n't change return type based on `char*` value (this was what Marcel use= d in his version), this would require `constexpr` arguments that probably w= ill be never added to language.

`const= expr` programming is not based on a 1:1 mapping between "type" an= d "value"; it's based on regular C++ programming principles. = On using different values for those types; we're just doing it a= t compile time instead of runtime. That's why its much better than tryi= ng to use template metaprogramming.

In short, you don't need<= /i> it to work this way. Once we can actually create and manipulate strings= at compile time, there's little point to using metaprogramming to proc= ess 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-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/750e= cf62-9637-40f4-8585-e3be2780fb46%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%2B0CCOV7Q= f21J-MBpdggkkrNt8Hs2dN03o52F0s-QXY6f%3Dcbw%40mail.gmail.com.
--001a11c022f001c410056504d601-- .