220 36884 <5c51d89a-54b6-490b-87f2-09ed263d8322@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: Mon, 12 Feb 2018 07:45:41 -0800 (PST) Lines: 552 Approved: news@gmane.org Message-ID: <5c51d89a-54b6-490b-87f2-09ed263d8322@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> <1e9a5468-6efa-48a2-87ce-6bdb6d5c4e83@isocpp.org> <750ecf62-9637-40f4-8585-e3be2780fb46@isocpp.org> <5b5435db-772e-4c38-8867-f6fbc66d7cec@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9609_446297566.1518450341499" X-Trace: blaine.gmane.org 1518450249 12363 195.159.176.226 (12 Feb 2018 15:44:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 15:44:09 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBJXNQ3KAKGQEMXDIA2Y@isocpp.org Mon Feb 12 16:44:05 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elGGY-0001Ch-7I for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 16:43:38 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id m190sf9312545vkg.5 for ; Mon, 12 Feb 2018 07:45:44 -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=OIDaDeh+Y8bPq0zRaBd5gZuzKnEu/HyEAMyXwiNi4iM=; b=Y5It1/Bllnh3U2g6yKieUHfvK+uy48JNVLdnSpODpq0loGbKrPNkt5ywcbP6ckeo/9 d5W9yr7NlYN8/uWeNlElZBIqgHHZXMZBxey+DJ7s9NLtxoS6hMIv+0ucgIUfDn5BHTRc rpXyDh9AljH+vtUYl08KKytDPmPmq9KWhlPqIcWCM3el804/boMdu02i0L4UAyqi+jI7 58FKkR+eOEtWiwHm6lX5gdYew1i1rH7n0cuu+wztuVoj4nuGd8yskn3BqkwurFWlGZoT oXQ/K/+24KMWqtNIPhz4Sp96yT+2ipiXJa+7IArgLv904JCD+Q9JQ6ADZ89JTbxBUJZe NdWQ== 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=OIDaDeh+Y8bPq0zRaBd5gZuzKnEu/HyEAMyXwiNi4iM=; b=X9HhS0Xxu11O3WjF6ebM9dN/b11+hICVlsKeRNYMUhFX6jQnNQtl4rUXO9zJKW7VaO kLM0mKh57ZDOSKLlWzLruT+aWroPKjsfYKnc92p/DIL8ikEy4LuiCzj1QHuN8RdSikRq jWM+k6laLFmBMvqScua9arTtn3GUqMma4x/0beNEEwvqFEto4uUH8LSpvek4Ug/A0YUM Jp6GzD22PYHQhk1gdqj2yKQCFLhU+ILhkz+Z4yOov7UThXKknh8xDqyIq6u5bzzm2IqR x7AjLXTfpDXefR5wqwCZtpNLHtuQQ1UYF3rQ+dP3J6Xjt6nZ/23cF/78bfFZr+FTDkpe DPxg== 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=OIDaDeh+Y8bPq0zRaBd5gZuzKnEu/HyEAMyXwiNi4iM=; b=A6+VvH8xS1x8Pgn0/xw2jSuTDaKbbvw9VZiqchHHh3gslE5oqYNRuHJ2+KzymCiqTa AkK++r7CJztyGsZqhyHI2jZwdpmYYtQSH5fy6oZQ3DxBYo5nx+brX08KDSfPeNfwKt6J p2sUVXX8waNTnGMK19Xo7ty05vYf3OwzTG+fuuqWWkRGd5OdAwiPkGfJQamANzSpZ25Z 4EtuZEeaykJZ8o7y6JQIdzddIZ5ke/9YI9mfOT2+dpQeoRw9w6RjXOLhCLGiUXGPGgZo pRTS49WO2y11A+BNrDjocSpf9Yb3BM1rwvOwEtfhkPf2PSX/AcDxx7SZKFfPWnV7XeKG q6lw== X-Gm-Message-State: APf1xPDjqfDysUaHJIivxRw6HLNJ8+vwhNJUnutIg6ZV/t4R5pOXePSb r5O2cbfpfIWWMoBwHvrlhKBveA== X-Google-Smtp-Source: AH8x224594uhGSNjI+os6oIzwOlBaRrV8J0Jup3UtFlN4f4k855AEBaLmch+UQFRIDze6/f7C7HQjg== X-Received: by 10.31.200.134 with SMTP id y128mr6334779vkf.65.1518450343705; Mon, 12 Feb 2018 07:45:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.67.196 with SMTP id q187ls7018750vka.21.gmail; Mon, 12 Feb 2018 07:45:42 -0800 (PST) X-Received: by 10.31.49.86 with SMTP id x83mr1075238vkx.0.1518450342017; Mon, 12 Feb 2018 07:45:42 -0800 (PST) In-Reply-To: <5b5435db-772e-4c38-8867-f6fbc66d7cec@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:36884 Archived-At: ------=_Part_9609_446297566.1518450341499 Content-Type: multipart/alternative; boundary="----=_Part_9610_952126848.1518450341501" ------=_Part_9610_952126848.1518450341501 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, February 12, 2018 at 10:14:25 AM UTC-5, floria...@gmail.com=20 wrote: > > Le lundi 12 f=C3=A9vrier 2018 15:56:12 UTC+1, Nicol Bolas a =C3=A9crit : >> >> On Monday, February 12, 2018 at 5:17:45 AM UTC-5, floria...@gmail.com=20 >> 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=20 >>> 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>> const char[7]&, std::string_view&, const char[2]&>("select ", column, "= =20 >>> from ", table, ";")); >>> >>> Now, if we want, we could also support UDL (but not mandatory) by=20 >>> 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>> string&, const char[7]&, std::string_view&, const char[2]&>("select ",= =20 >>> 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= =20 >>> 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= =20 >>> 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= =20 >>> 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=20 >>> 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= =20 >>> to keep it simple. And use a library based solution when I really need= =20 >>> formatting. >>> >>> It has all the advantages of Nicol's solution, while being more=20 >>> versatile. >>> >> >> I fail to see the versatility here, and it does not have all of the=20 >> advantages of my method. >> >> Remember, in my version, UDLs only apply to the string fragments. In you= r=20 >> version, you *cannot* apply UDLs to string fragments; the string=20 >> fragments will be packed into your `string_processing` type as views or= =20 >> some such. >> >> Then there's ease of use. Let's see how to implement stream-based string= =20 >> 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 programmin= g. >> >> Now, how would you go about doing that with `string_processing`? That=20 >> 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> Args)>{}); >> return std::move(stream).get(); >> } >> >> This isn't the hardest code to write in the world, but it is much more= =20 >> complex than the previous one. Also, perfect forwarding doesn't really w= ork=20 >> here. >> >> Also, the variadic version of `concat` can be used with stuff that isn't= =20 >> the result of string interpolation. Or with multiple interpolated string= s.=20 >> And so forth. Whereas your `string_processing` type is a magic type that= =20 >> only the compiler can create. And we already have a type that does what= =20 >> `string_processing` does; it's called `tuple`. >> >> The *only advantage* your method has over mine is that it allows UDLs to= =20 >> define the aggregation operation. Why is this so important to so many=20 >> people? >> >> > > Well, my solution is more versatile in the following sense: the result is= =20 > a plain object that can be stored in a variable, returned from a function= .. > tuple(F"interpolated {string}") Oh look, "a plain object that can be stored in a variable, returned from a= =20 function". It required a whole 7 characters more. "Versatility" typically refers to the ability to do more things with=20 something. My way can be put into an object, but your way cannot be put=20 into a function's parameters as separate values nearly as easily. Mine=20 seems more versatile. You could envision functions to transform std::string_processing into=20 > another std::string_processing easily. > > Moreover, I know that some proposals try to enable creating a parameter= =20 > pack from a tuple (like an operator... ). > And sadly, none of them have advanced or even received additional revised= =20 proposals. My way works just fine with C++ as it is. And even if we had that, most use-cases you don't need to pass the values= =20 around as a collective object. And if you did, you can make one trivially,= =20 as above. And again, it still doesn't deal with the fact that you lose perfect=20 forwarding. With that in mind, the implementation of your concat function with my=20 > approach would be exactly the same as with your approach (with a call to= =20 > "operator..." of std::string_processing ). > > And then, with only c++17 metaprogramming capabilities, you could also us= e=20 > std::apply. > You cannot `apply` things to operators. Not without creating a lambda=20 function that gets called with it. The fact is, it's a *lot* easier in C++ as it currently stands to go from= =20 parameter pack of values to an object than it is to go from an object to a= =20 parameter pack of values. I wish that were not the case, but so long as it= =20 is the case, parameter packs will remain the easier-to-use option. UDL the aggregate is not important to me, but it was easy to include and=20 > allows neat syntax (in my opinion). > But it makes it impossible to apply a UDL to the string fragments. And=20 that's important if you do want to use template metaprogramming on string= =20 literals. --=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/5c51d89a-54b6-490b-87f2-09ed263d8322%40isocpp.or= g. ------=_Part_9610_952126848.1518450341501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, February 12, 2018 at 10:14:25 AM UTC-5, floria.= ...@gmail.com wrote:
Le lundi 12 f=C3=A9vrier 2018 15:56:12 UTC+1, Nicol Bolas a =C3=A9cri= t=C2=A0:
On Monday,= February 12, 2018 at 5:17:45 AM UTC-5, floria...@gmail.com wrote:
Let me suggest somet= hing 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"<= /span>sv;
auto req =3D sql(F"selec= t {column} from {table};");

// would= be equivalent to:
auto req =3D sql(std::string_processing<cons= t char<= /span>[8]&, std::string<= /span>&, <= /span>const char[7]&, std::string_view= &, = const c= har[2]&>("select ", column, " from ", table, ";"));<= /span>

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<= span style=3D"color:#000"> req =3D= F"select= {column} from {table};"_sql<= span style=3D"color:#660">;

// would be equivalent to:
auto req =3D operator ""_sql (std::string_processing&l= t;const= char[<= /span>8]&,= std::<= /span>string&a= mp;, co= nst cha= r[7]&, std= ::strin= g_view&, const char[2]&a= mp;>("select ", column, " from ", table, ";"= ;));

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

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

W= e could print it into an iostream if we want (but would be here only for co= nvenience on legacy code)
=
std::cout <&l= t; F&qu= ot;{str1}{str2}\n";
// equivalent to:
std::<= /span>cout <= ;< str1 << str2 << "\n";

It could be implicit= ly convertible to a std::string (only if variables are implicitly convertib= le to std::string)
std::string concatenate= d =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 thi= s 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, U= DLs only apply to the string fragments. In your version, you cannot = apply UDLs to string fragments; the string fragments will be packed into yo= ur `string_processing` type as views or some such.

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

template<= typename ...Ar= gs><= br>auto= concat(Args .= ...&&args)
{
=C2=A0 std::ostringstream stream;
=C2= =A0 stream << ... << std::forward<Args>(args);
=C2=A0 return= std::<= span style=3D"color:#000">move(stream).get();
}

Simple and obvious, a standard bit of C++17 variadic temp= late programming.

Now, how would you go about doing that with `strin= g_processing`? That would require template metaprogramming:

templ= ate<= typename ...Args, size_t ...Ints>
void concat_items(std::ostringstream = &stream, std::string_pro= cessing<Args...> &&proc, std::index_sequence<= Ints...>)
{
=C2=A0 stream << ... << get<Ints>(proc));
}

template<typename ...Args>
auto concat(std::string_processing<= Args...> &&proc)
{
=C2=A0 std::ostringstream stream;
=C2= =A0 concat_items(stream, std::move(proc), std::make_index_sequence<size...(= Args)>{});<= /span>
=C2=A0 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, perf= ect forwarding doesn't really work here.

Also, the variadic vers= ion 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 c= reate. And we already have a type that does what `string_processing` does; = it's called `tuple`.

The only advantage your method has o= ver mine is that it allows UDLs to define the aggregation operation. Why is= this so important to so many people?

=

Well, my solution is more versatile in the following sen= se: the=20 result is a plain object that can be stored in a variable, returned from a function.

tuple(F"interpolated {string}")

Oh loo= k, "a plain object that can be stored in a variable, returned from a function". It required a whole 7 characters more.

"Vers= atility" typically refers to the ability to do more things with someth= ing. My way can be put into an object, but your way cannot be put into a fu= nction's parameters as separate values nearly as easily. Mine seems mor= e versatile.

You could envision functions to transform std::string_pro= cessing into another std::string_processing easily.

Moreover, I know that some proposals try to enable creating a parameter p= ack from a tuple (like an operator... ).

A= nd sadly, none of them have advanced or even received additional revised pr= oposals. My way works just fine with C++ as it is.

And even if we ha= d that, most use-cases you don't need to pass the values around as a co= llective object. And if you did, you can make one trivially, as above.
<= br>And again, it still doesn't deal with the fact that you lose perfect= forwarding.

With that in mind, the implementation of your concat func= tion with my approach would be exactly the same as with your approach (with= a call to "operator..." of std::string_processing ).
<= br>
And then, with only c++17 metaprogramming capabilities, you c= ould also use std::apply.

You cannot `= apply` things to operators. Not without creating a lambda function that get= s called with it.

The fact is, it's a lot easier in C++ a= s it currently stands to go from parameter pack of values to an object than= it is to go from an object to a parameter pack of values. I wish that were= not the case, but so long as it is the case, parameter packs will remain t= he easier-to-use option.

UDL the aggregate is not imp= ortant to me, but it was easy to include and allows neat syntax (in my opin= ion).

But it makes it impossible to apply a = UDL to the string fragments. And that's important if you do want to use= template metaprogramming on string literals.

--
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/5c51d89a-54b6-490b-87f2-09ed263d8322= %40isocpp.org.
------=_Part_9610_952126848.1518450341501-- ------=_Part_9609_446297566.1518450341499-- .