220 36891 article Path: news.gmane.org!.POSTED!not-for-mail From: florian.csdt@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: String interpolation Date: Mon, 12 Feb 2018 13:08:36 -0800 (PST) Lines: 483 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> <5b5435db-772e-4c38-8867-f6fbc66d7cec@isocpp.org> <5c51d89a-54b6-490b-87f2-09ed263d8322@isocpp.org> <305b7669-0744-473e-9715-807b7e8051b6@isocpp.org> <0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549@isocpp.org> <41b87b07-1a91-4bca-ba00-5734c09dbe77@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_10474_1553800702.1518469716932" X-Trace: blaine.gmane.org 1518469599 18963 195.159.176.226 (12 Feb 2018 21:06:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 21:06:39 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC26HM4V3MIRBVUERDKAKGQELY4PVHI@isocpp.org Mon Feb 12 22:06:35 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elLJ4-0004X4-3C for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 22:06:34 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id y43sf10972303uac.16 for ; Mon, 12 Feb 2018 13:08:40 -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=9vLo2SAQG4sX2Kj8DmgLLDaWDdg/CmUXYnJlNUpNVAM=; b=XNmwJVTHHRBVmLKRJ+SAnQv1fxNwVS0bxrnwCRMtI0JGycTBUMLTC80hvhhgnjOx8A 6LSov2KytwT50TOilGsOyW3X2rLQpHAJElY8n8H99obCZG11vXOOTWGJiEhjaMKFPM3W DsaUtMlilXDG/ofUuBgWWa6dO6QlPLMv6TDPkYiWLcncano1O0tlvi4T9V0WcCyeaYAH zqXb1nE5b8joHsdhyIPX3EtdNMlmEZ7wjLlMHmLzWQ8II+b7OKqZc7gMJrA5ZUhesc98 Q03dT2XockoGAbUM8FAIgSJdszA1zzo1pFRuFI4KGXjrpa2MK8BchEBWg4PwEpt6KkOw DLkg== 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=9vLo2SAQG4sX2Kj8DmgLLDaWDdg/CmUXYnJlNUpNVAM=; b=pkgweKB/ftRsGvIvkroBQ1Fv+RK5ShAXqepQrEzwLXNMV3rAcuvcCuRQTnxTkjyMKl QBAzq/U+xzDOzYlzrB8wjunoVupLxxbcDHYXgJj9kR0kqlGw85vjxtQX8rLUxKwTYvxh keeQWQnREg4QwiaDuTOSEzT0mVSTrL++X1l8onKv+fmtTuH8xp3Foywn6GDf17rJPQ0n /SMGNB5AhcpnlEV88xjexNhJz0D7GNFEcj/AMvF+8UojljBQTzLM7jRvAMIcmBoGtjTd qMvNa5m54zvtF/Tajg6s1mgC+qV7EUv4cOCa1Cd1ehb5cKrr6kIHt76Mtf4krHQuIIcS l76g== 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=9vLo2SAQG4sX2Kj8DmgLLDaWDdg/CmUXYnJlNUpNVAM=; b=Bif2he4JCXiJBCigfkq919i2li1nEXxiVaRDw8eczqm4GiqXhzNSEYotf7VSqwqeni whBDpQB8wEeR/894RVEvLzyJCdNgl7HBQswc7WbTzrpyVolvF55ynzq9Ymjc79qKlqP0 2Vw/3lD/SFXyvySrfKm1vy1beMx2zouVCGUw9lE2E1bKVC/jV46OSRsKN05LBzqjEyji 8oAAdb4RGflPu33thyE/DQVHuBy44Qb3rpr5cYSwRn56/B6BUGoygOOAiLjy64gVeAKW fGZsYbmJbpt+gYzkDobPrqKLRGyQJOQjTswutnYGmqbgKRZofvoLNAgKoqty8/vPnf7C VZbA== X-Gm-Message-State: APf1xPAF7lsrpkBKaKOMjBBDHYUgwg0l/xK0aVQBX1UNUXqRI+3xxlwE 9mh5rDY9rEvKhe2v6TZWMCjJbQ== X-Google-Smtp-Source: AH8x227aH141xZQW/oKZCcX4e0B+nvPVi79ve9QhOpFEu8YEsjOteSQzuHyp8C0RiO1JnygtZN8jEA== X-Received: by 10.176.81.161 with SMTP id g30mr7030285uaa.57.1518469719644; Mon, 12 Feb 2018 13:08:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.147.150 with SMTP id v144ls7573738vkd.2.gmail; Mon, 12 Feb 2018 13:08:37 -0800 (PST) X-Received: by 10.31.159.216 with SMTP id i207mr765313vke.12.1518469717497; Mon, 12 Feb 2018 13:08:37 -0800 (PST) In-Reply-To: <41b87b07-1a91-4bca-ba00-5734c09dbe77@isocpp.org> X-Original-Sender: florian.csdt@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:36891 Archived-At: ------=_Part_10474_1553800702.1518469716932 Content-Type: multipart/alternative; boundary="----=_Part_10475_1336774937.1518469716933" ------=_Part_10475_1336774937.1518469716933 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le lundi 12 f=C3=A9vrier 2018 21:11:14 UTC+1, Nicol Bolas a =C3=A9crit : > > On Monday, February 12, 2018 at 12:43:41 PM UTC-5, floria...@gmail.com=20 > wrote: >> >> Le lundi 12 f=C3=A9vrier 2018 17:56:48 UTC+1, Nicol Bolas a =C3=A9crit : >>> >>> On Monday, February 12, 2018 at 11:15:33 AM UTC-5, floria...@gmail.com= =20 >>> wrote: >>> >> 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 cal= l to=20 >>>>>> "operator..." of std::string_processing ). >>>>>> >>>>>> And then, with only c++17 metaprogramming capabilities, you could=20 >>>>>> also use std::apply. >>>>>> >>>>> >>>>> You cannot `apply` things to operators. Not without creating a lambda= =20 >>>>> function that gets called with it. >>>>> >>>> =20 >>>> Why not? You can get the address of an operator, and this is a callabl= e=20 >>>> object. >>>> >>> >>> You can only get the address of a single overload of an operator.=20 >>> Remember: the whole idea is that you're dealing with a sequence of=20 >>> variables of different types. So the second parameter to the operator h= as=20 >>> to be of different types for different invocations of the operator. >>> >> >> This is another quirk of C++ that should be fixed. >> > > Which incidentally is yet another proposal (lifting lambdas) that stalled= .. > > 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. >>>>> >>>> =20 >>>> You have a point.=20 >>>> >>>> >>>>> UDL the aggregate is not important to me, but it was easy to include= =20 >>>>>> and allows neat syntax (in my opinion). >>>>>> >>>>> >>>>> But it makes it impossible to apply a UDL to the string fragments. An= d=20 >>>>> that's important if you do want to use template metaprogramming on st= ring=20 >>>>> literals. >>>>> >>>> >>>> I'm not sure to see the use case here. When you use UDL, you want the= =20 >>>> whole literal to be what you say it would be. >>>> auto s =3D "something"s; // s is a string >>>> auto sv =3D "some other"sv; // s is a string view >>>> We are not interested in what is happening in the middle. I don't why= =20 >>>> it should be different with string interpolation (or whatever the name= is). >>>> >>> >>> Because not all of the "literal" is actually a literal anymore. That's= =20 >>> the whole point of string interpolation: you're taking a literal and yo= u're=20 >>> augmenting it with some non-literal data. Potentially *runtime*=20 >>> non-literal data. It isn't a literal anymore, so the UDL suffix can't a= pply=20 >>> to the aggregate. It can only apply to the individual literal fragments= of=20 >>> the string. >>> >> >> Here, I don't care if it's called a literal, or if we invent a new name= =20 >> for this concept that appeared to match the concept of literal when "str= ing=20 >> interpolation" was not a thing. >> I'm more interested in the final syntax as the end user will see it. >> >> And I would prefer concatenate like this: >> auto s =3D F"{str1}{str2}{str3}"s; >> than this: >> auto s =3D std::concat(F"{str1}{str2}{str3}"); >> >> The first one looks more natural in my opinion. >> > > It only looks more natural for the trivial cases. Consider what=20 > `std::concat` would look like. It creates an `ostringstream`, applies it = to=20 > each parameter, and moves its result out. Why pick `ostringstream`? Why n= ot=20 > allow the user to decide which kind of stream to use and therefore which= =20 > resulting string type to build? > I never said this should work only with UDL. I just said that I think it is= =20 more natural if UDL worked like that. But I really think the user should keep control over what can be done with= =20 this syntax. So I totally agree with you: users should be able to call their own=20 functions with it. And then, even considering F"{str1}{str2}{str3}"s for concatenating, I=20 never mentionned std::ostringstream, I just said converted into an=20 efficient way of concatenating strings. In that case, I just considered that when we use operator ""s, we want a=20 std::string. =20 > > You can't do that with a UDL; they can't take an extra template parameter= ..=20 > `std::concat` can. > To do that, just use a function. We can have multiple syntaxes to do the=20 same thing. The closest example I can think of is: auto s =3D std::string("str"); // is equivalent to auto s =3D "str"s; We could have exatcly the situation with string interpolation: auto s =3D std::concat(F"{str1}{str2}{str3}"); // would be equivalent to auto s =3D F"{str1}{str2}{str3}"s; I don't see why allowing UDL to work like that would decrease usability as= =20 we could always use regular functions. =20 > > However more "natural" the UDL version *appears*, it's ultimately much=20 > more limiting to *use*. And while appearance is important, usability=20 > ought to be more important. > > You can't even do this in a header: > > struct Foo > { > std::string value =3D F"{str1}{str2}{str3}"s; > }; > > That's due to having to `using namespace` the literals before you can use= =20 > them. Calling a function directly requires no such gymnastics. > But you could always do this: struct Foo { std::string value =3D std::literals::string_literals::operator ""s(F "{str1}{str2}{str3}"); }; At least if the UDL is not templated. But as templated UDLs are not made=20 for string literals according to the standard (and this is completely=20 stupid, btw), we are completely fine here. And it goes in the same direction as your previous post: we should not try= =20 to make UDL easier to use for regular string computation. In that case, it= =20 is not easier, just possible. =20 > > Oh sure, modules will (thankfully) remedy this situation to a degree. But= =20 > until everyone's codebase is modularized, that's going to be a problem. A= nd=20 > even then, you shouldn't have to `using namespace blah` to be able to use= =20 > string interpolation. > I never ever said we should use a namespace or rely on UDL to be able to=20 use string interpolation. I just said how I tried to see how UDL would/should/could interact with=20 string interpolation. --=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/ef8fbc4c-08c0-409e-815b-28e161101231%40isocpp.or= g. ------=_Part_10475_1336774937.1518469716933 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Le lundi 12 f=C3=A9vrier 2018 21:11:14 UTC+1, Nico= l Bolas a =C3=A9crit=C2=A0:
On Monday, February 12, 2018 at 12:43:41 PM UTC-5, floria.= ...@gmail.com wrote:
Le lundi 12 f=C3=A9vrier 2018 17:56:48 UTC+1, Nicol Bolas a =C3=A9crit= =C2=A0:
On Monday, = February 12, 2018 at 11:15:33 AM UTC-5, floria...@gmail.com wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border= -left:1px #ccc solid;padding-left:1ex">
With that in mind, the implementation = of your concat function with my approach would be exactly the same as with = your approach (with a call to "operator..." of std::string_proces= sing ).

And then, with only c++17 metaprogramming = capabilities, you could also use std::apply.

You cannot `apply` things to operators. Not without creating a lambd= a function that gets called with it.
=C2= =A0
Why not? You can get the address of an operator, and this is = a callable object.

You can only get the ad= dress of a single overload of an operator. Remember: the whole idea is that= you're dealing with a sequence of variables of different types. So the= second parameter to the operator has to be of different types for differen= t invocations of the operator.

<= div>This is another quirk of C++ that should be fixed.

Which incidentally is yet another proposal (lifting lambda= s) that stalled.

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


=
UDL the aggregate is not important to me, but it was easy to include an= d allows neat syntax (in my opinion).

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 literal= s.

I'm not sure to see = the use case here. When you use UDL, you want the whole literal to be what = you say it would be.
auto s = =3D "something"s; // s is a string
auto sv =3D "some other"<= /span>sv; // s is a s= tring view
W= e are not interested in what is happening in the middle. I don't why it= should be different with string interpolation (or whatever the name is).

Because not all of the "literal&qu= ot; is actually a literal anymore. That's the whole point of string int= erpolation: you're taking a literal and you're augmenting it with s= ome non-literal data. Potentially runtime non-literal data. It isn&#= 39;t a literal anymore, so the UDL suffix can't apply to the aggregate.= It can only apply to the individual literal fragments of the string.

Here, I don't care if it'= ;s called a literal, or if we invent a new name for this concept that appea= red to match the concept of literal when "string interpolation" w= as not a thing.
I'm more interested in the final syntax as th= e end user will see it.

And I would prefer concate= nate like this:
auto s =3D F= "{str1}{str2}{str3}"s;
than this:
auto s =3D std::concat(F&qu= ot;{str1}{str2}{str3}");=

The first one = looks more natural in my opinion.

It o= nly looks more natural for the trivial cases. Consider what `std::concat` w= ould look like. It creates an `ostringstream`, applies it to each parameter= , and moves its result out. Why pick `ostringstream`? Why not allow the use= r to decide which kind of stream to use and therefore which resulting strin= g type to build?

I never sa= id this should work only with UDL. I just said that I think it is more natu= ral if UDL worked like that.
But I really think the user should k= eep control over what can be done with this syntax.
So I totally = agree with you: users should be able to call their own functions with it.

And then, even considering F"{str1}{str2}{str3= }"s for concatenating, I never mentionned std::ostringstream, I just s= aid converted into an efficient way of concatenating strings.
In = that case, I just considered that when we use operator ""s, we wa= nt a std::string.
=C2=A0

You can't do that with a UDL; t= hey can't take an extra template parameter. `std::concat` can.

To do that, just use a function. We= can have multiple syntaxes to do the same thing.
The closest exa= mple I can think of is:
auto s =3D std= ::string("str");
// is equivalent to
auto s =3D "str"s;

We could ha= ve exatcly the situation with string interpolation:
auto s =3D std::concat(F&q= uot;{str1}{str2}{str3}");
// would be equivalent to
auto s = =3D F"{str1}{st= r2}{str3}"s;

I don't see why allowing UDL to work like that wou= ld decrease usability as we could always use regular functions.
=C2=A0

However more "natural" the UDL version appears,= it's ultimately much more limiting to use. And while appearance= is important, usability ought to be more important.

You can't e= ven do this in a header:

struct= Foo{
= =C2=A0 std::string value =3D F"{str1}{str2}{str3}"s<= /span>;
};

That's d= ue to having to `using namespace` the literals before you can use them. Cal= ling a function directly requires no such gymnastics.

But you could always do this:
struct= Foo
{
=C2=A0 std::string value = =3D std::literals::string_= literals::= operator ""s(F= "{str1}{str2}{str3}");
};
At least if the= UDL is not templated. But as templated UDLs are not made for string litera= ls according to the standard (and this is completely stupid, btw), we are c= ompletely fine here.
And it goes in the same direction as your previous = post: we should not try to make UDL easier to use for regular string comput= ation. In that case, it is not easier, just possible.
=C2=A0<= /div>
Oh sure, modules will (thankfully) remedy this situation to a degree. But = until everyone's codebase is modularized, that's going to be a prob= lem. And even then, you shouldn't have to `using namespace blah` to be = able to use string interpolation.

I never ever said we should use a namespace or rely on UDL to be able to= use string interpolation.
I just said how I tried to see how UDL= would/should/could interact with string interpolation.

--
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/ef8fbc4c-08c0-409e-815b-28e161101231= %40isocpp.org.
------=_Part_10475_1336774937.1518469716933-- ------=_Part_10474_1553800702.1518469716932-- .