220 36880 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Mon, 12 Feb 2018 06:56:12 -0800 (PST) Lines: 464 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/mixed; boundary="----=_Part_9306_726954476.1518447372737" X-Trace: blaine.gmane.org 1518447262 15473 195.159.176.226 (12 Feb 2018 14:54:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 14:54:22 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDOWQ3KAKGQEGEHXORA@isocpp.org Mon Feb 12 15:54:18 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f71.google.com ([209.85.213.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elFUf-0003Jl-Gx for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 15:54:10 +0100 Original-Received: by mail-vk0-f71.google.com with SMTP id y11sf3737691vkd.11 for ; Mon, 12 Feb 2018 06:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=eX3azFsY3ALqf6oFqgrxerrp1ykeRIvx9tqqpIqmitc=; b=uZaDKKkZ3XYOlUiA7W3t5pdTVe4oeXbVP+V5Zeur+7Pn9r+uMiKuG7NoQbGEGakwUZ gq3f1HS3dAAa4WOqy8BjDFJg5GrupzZEZJjC/lhJiaFLhs2ZFoWXSX4N7Y3TRDKycXxW IYkKwwFXgT2ExLkBsot66uK5Ok6oykbovvW3K/ZUCSYonIEPCfPm0ZMvcRnAJLinVKBG CVl+RVfqC9wm2y2bCJjv3ZTyfEt16W5XK6G7xhBIfZW5+9S9arBNHgm6smUx0QDZUTJD WE+30kr36nu/JUgENLQgXQKjGz/xq1KVzc+iHQ98WFfRfTk2ZwTXSrzz7NgPHXOysy9o LA9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=eX3azFsY3ALqf6oFqgrxerrp1ykeRIvx9tqqpIqmitc=; b=cS6quFsKQzoeinbwynTgjnG9ektqFNwIyG+oTORgX6JKvjwmXozhHJyrk9N+H5uuXm 8wbP5CaWPoPYtm+gHuszceZtq15weYzhbYqG7aO7Awvb9mReosT697CKD7Hhv8yxXLi/ guuRrIIICltzjTjQyzKbc9WtMoBZwFhbU/JIyor7VZNpbratlnfgRl0niHS4qLerJABt 088UcTt0mz36syHdnn+3Gz8f+R8UMWZnF1fyjkBt49DEr+3viqzdcRvq+p0xHC5u4unw wFJW7HUtgCZnw2va3y5piVPhU8CpJwwdCAebIQD2wY4N4gZYQi6zew0jT2wncUQyhqbg PS2Q== 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:cc: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=eX3azFsY3ALqf6oFqgrxerrp1ykeRIvx9tqqpIqmitc=; b=J7glIuFvOOCdg2Lqz45N3y+HDidRCkMKMsTdKssTtjirfqpTq6c6P9ZxnPy51/4aC8 PngpVCvJPr/XTQwfHKdpwVzrL2uiQnVeboGkhFBK6XgyFmAJ0Zzc++HnneCz0E3ve0Wz X4CmKmBkbZrPJa3f58JZP2avLO2IhGmENHqukfmWPA1lB/IHv1+NnER9LNti5qqntDqE Ks1hiK/zmePOcCS1RPp89xBioJdUp1zNdqswjWeIOf+/Dw+9Nh5O109926lsC7wKr2Vl zKlJPU+QUuDLgjYjPDK/wgus5oar7aKiUIF6daEBnhDnaQrRDSMKkoMvLqzdsjKsrvKA DUVA== X-Gm-Message-State: APf1xPBRNNosITuvCAPu6jdmoj2rulvtBVsPZUuhz3HkjX/yLp8k83s3 H97e7pu1psP83H6aCNL0AY+//Q== X-Google-Smtp-Source: AH8x225XS6gW4FBd8UkEvInOjysO+FJbLy0tCq6Rjkz5kD/7bCQWyy5o0Kvh/sCMnyvjmQ9tOcA1QQ== X-Received: by 10.31.224.199 with SMTP id x190mr6126997vkg.90.1518447375080; Mon, 12 Feb 2018 06:56:15 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.164.68 with SMTP id n65ls7122282vke.0.gmail; Mon, 12 Feb 2018 06:56:13 -0800 (PST) X-Received: by 10.31.128.137 with SMTP id b131mr1062546vkd.7.1518447373303; Mon, 12 Feb 2018 06:56:13 -0800 (PST) In-Reply-To: <750ecf62-9637-40f4-8585-e3be2780fb46@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:36880 Archived-At: ------=_Part_9306_726954476.1518447372737 Content-Type: multipart/alternative; boundary="----=_Part_9307_1016462171.1518447372739" ------=_Part_9307_1016462171.1518447372739 Content-Type: text/plain; charset="UTF-8" On Monday, February 12, 2018 at 5:17:45 AM UTC-5, floria...@gmail.com 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 = "col"s; > auto table = "tab"sv; > auto req = sql(F"select {column} from {table};"); > > // would be equivalent to: > auto req = sql(std::string_processing char[7]&, std::string_view&, const char[2]&>("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 = "col"s; > auto table = "tab"sv; > auto req = F"select {column} from {table};"_sql; > > // would be equivalent to: > auto req = operator ""_sql (std::string_processing string&, const char[7]&, std::string_view&, const char[2]&>("select ", > column, " from ", table, ";")); > > Now let's have some examples of it could be: > > Simple string concatenation would be simple > auto concatenated = 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 = 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. > I fail to see the versatility here, and it does not have all of the advantages of my method. Remember, in my version, UDLs only apply to the string fragments. In your version, you *cannot* apply UDLs to string fragments; the string fragments will be packed into your `string_processing` type as views or some such. Then there's ease of use. Let's see how to implement stream-based string concatenation with my method: template auto concat(Args ...&&args) { std::ostringstream stream; stream << ... << std::forward(args); return std::move(stream).get(); } Simple and obvious, a standard bit of C++17 variadic template programming. Now, how would you go about doing that with `string_processing`? That would require template metaprogramming: template void concat_items(std::ostringstream &stream, std::string_processing &&proc, std::index_sequence) { stream << ... << get(proc)); } template auto concat(std::string_processing &&proc) { std::ostringstream stream; concat_items(stream, std::move(proc), std::make_index_sequence{}); return std::move(stream).get(); } This isn't the hardest code to write in the world, but it is much more complex than the previous one. Also, perfect forwarding doesn't really work here. Also, the variadic version of `concat` can be used with stuff that isn't the result of string interpolation. Or with multiple interpolated strings. And so forth. Whereas your `string_processing` type is a magic type that only the compiler can create. And we already have a type that does what `string_processing` does; it's called `tuple`. The *only advantage* your method has over mine is that it allows UDLs to define the aggregation operation. Why is this so important to so many people? -- 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/f8f4407b-ecf6-4a4a-b3f6-c65813e3f843%40isocpp.org. ------=_Part_9307_1016462171.1518447372739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, February 12, 2018 at 5:17:45 AM UTC-5, floria..= ..@gmail.com wrote:
Let me suggest something close to Nicol's solution, but not quite.=

The F"" operator returns a special type that could be lik= e a simple tuple (let's name it std::string_processing for now).
Then the user can use it directly into its own functions.


au= to 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::s= tring_processing<const char[8]&, std::string&, const char[7]&, std::string_view&, const char[2]&>("select ", column, &= quot; 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 &qu= ot;col"s;
auto table =3D "tab"sv;
auto req =3D F"select {column} from {table};"_sql;

// would be equiv= alent to:
auto req =3D operator ""_sql (std::string_processing<const char[8]&, std= ::string&, const = char[7]&,<= span style=3D"color:#000"> std::string_view&= , const= char[2= ]&>(&qu= ot;select ", column, " from ", table, ";"));=

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

Simple string concatenation would= be simple
auto concatenated =3D F<= span style=3D"color:#080">"{str1}{str2}{str3}"s;
// converted into an effic= ient 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 style=3D"color:#080">"{str1}{str2}\n";
// equivalent to:
std<= span style=3D"color:#660">::cout <= span style=3D"color:#660"><< str1 <= /span><<= str2 << "\n";
=

It could be implicitly convertible to a std::string (only if vari= ables 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 compat= ible with FMT.)

And this would be constexpr-able.

Now, format= ting would require a bit more elaborated type that could store formatting i= nformation.
But in the end, only the user will know what to do with it.<= br>However, I would prefer not to embed formatting in such a type, j= ust 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.

I fail to see the ver= satility here, and it does not have all of the advantages of my method.
=
Remember, in my version, UDLs only apply to the string fragments. In yo= ur version, you cannot apply UDLs to string fragments; the string fr= agments will be packed into your `string_processing` type as views or some = such.

Then there's ease of use. Let's see how to implement s= tream-based string concatenation with my method:

template<typename ...Args>
auto= concat(Args<= span style=3D"color: #000;" class=3D"styled-by-prettify"> ...&&args)
{
=C2=A0 std::ostringstream stream;
=C2=A0 stream << ... <<= std::forward= <Args>(args);
=C2=A0 return std::move(stre= am).get();
}

Sim= ple and obvious, a standard bit of C++17 variadic template programming.
=
Now, how would you go about doing that with `string_processing`? That w= ould require template metaprogramming:

template<typename ...Args, si= ze_t ...Ints<= span style=3D"color: #660;" class=3D"styled-by-prettify">>
void concat_items(std::ostringstream &stream, std= ::string_p= rocessing&= lt;Args...> &&proc, std::index_sequence<Ints...>)
{
= =C2=A0 stream << ... << get<Ints>(proc));
= }

<= /span>template<typename ...Args>
auto concat(std:= :string_pr= ocessing&l= t;Args...>= &&proc)
{
=C2=A0 std::ostringstream stream;
=C2=A0 concat_items(stream, std::move(proc), std::make_index_sequence<size...(Args)>{});
=C2=A0 return std::move(stream).get();
}

This isn't the h= ardest code to write in the world, but it is much more complex than the pre= vious one. Also, perfect forwarding doesn't really work here.

Al= so, the variadic version of `concat` can be used with stuff that isn't = the result of string interpolation. Or with multiple interpolated strings. = And so forth. Whereas your `string_processing` type is a magic type that on= ly the compiler can create. And we already have a type that does what `stri= ng_processing` does; it's called `tuple`.

The only advantage<= /i> your method has over mine is that it allows UDLs to define the aggregat= ion operation. Why is this so important to so many people?

--
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/f8f4407b-ecf6-4a4a-b3f6-c65813e3f843= %40isocpp.org.
------=_Part_9307_1016462171.1518447372739-- ------=_Part_9306_726954476.1518447372737-- .