220 36890 <41b87b07-1a91-4bca-ba00-5734c09dbe77@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 12:11:14 -0800 (PST) Lines: 311 Approved: news@gmane.org Message-ID: <41b87b07-1a91-4bca-ba00-5734c09dbe77@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> <5c51d89a-54b6-490b-87f2-09ed263d8322@isocpp.org> <305b7669-0744-473e-9715-807b7e8051b6@isocpp.org> <0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1121_1201974013.1518466274401" X-Trace: blaine.gmane.org 1518466161 18254 195.159.176.226 (12 Feb 2018 20:09:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 20:09:21 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBY7JQ7KAKGQE2PT7FGI@isocpp.org Mon Feb 12 21:09:16 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1elKPX-00049J-2Z for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 21:09:11 +0100 Original-Received: by mail-ua0-f197.google.com with SMTP id y43sf10868123uac.16 for ; Mon, 12 Feb 2018 12:11:17 -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=vQuzqHFET5vpf2Ti0HAQvvnqCYq3sU1jkz3s2sqlLhs=; b=y9Jbhr4w9xFfitPF3oHkjTiJX4OXsumFUJhgut7cph5Oq+oHyCn3NryTmZz9mKn+UB 0+C3cd80U7Iq+/eSFm/uTEnk3GOvQ+bhxu5/nHybDksDnnETjOb2TnRNDkcPsqlSMBfB 1mbWabHeNcVMEDB4bu/hXTkRupeQ4dlM0cNlxaiKl9GWzxazC3pglrrk+RDX8+ulpFAX d6k/M4ncE+dZYeYs9bKhNQ3u625eEue3nFKjbR4HoFOKfo4pjrP5hpC+bFcwpXSfuf4w iNfikto4tgAsId0iLjEXmkyDS2+U/qsjlFQreymBnU7NeGtIQb/m9A4CsG17oTuxQLi9 r4vg== 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=vQuzqHFET5vpf2Ti0HAQvvnqCYq3sU1jkz3s2sqlLhs=; b=IwrjB/IdwPpdtg4KaxMHgEIjI3w03JvpfpnnUhbGO4NyJZF/GfVh5fSmpruXHGSxw9 7IHmK/A8SMU/Hd+MwZRKR/poE94nDrsdjQ7TUE44DZRF9K6zY4kA7QDVYFN7/XV3CKcK dmRCKlGddjX/4Ug/rIpZcCFSW5qWZ8HNHrUHZooZODtlv9liW+SJVZEslkct600prLYR wPbl8frDe7ZjoaEgQNbomZ6D5sL8+TnWW/S4dS/EPVbIJ+EacmpOwvYYif3IVhCtKiNJ nBPxupSdkfUhHlobN25S2/3Mh5lVW9ats/sXYnfAxw1RH3MzePbep01Tl9zgs/3bK5jU 2JEg== 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=vQuzqHFET5vpf2Ti0HAQvvnqCYq3sU1jkz3s2sqlLhs=; b=WD16T+VLEi03bsd3VEje64htNuX8a7N+mE5HqlirV3/sN8j3Zu5zuHZ4MlbQNx0ECK QwVSLjfbQDZ6e8BDD8kQT+hu3AOvnUpFxlnpwZX1aCidUrdNBYvJGqdUIXga8nzvZ5te 43BRfNmLIkeQRVX3dM3ftQJgVAQTppFF3qUe+hIjGRLNjv7DPcxx2BXM/P6R/jP8vuZ1 sFFqPVLlbRprKUU5ciqdWzBWnJwH+5Wfn7ktlXiD+6svDyKWqnl+qZtjmhimVnmT+279 Q4tkM6dRq4OT17VWBHt3sFBnAxXoqNsV0QXbDVOR+QNXP/mF/+tF4o+TOde3NtKWHWuC Na1w== X-Gm-Message-State: APf1xPBZQBljI/1UyRTaj0THP2KMV3q0maOJ+F1PzfC75c4izzLtynIT 9i12c691MRSWDUpQ8BTXWpoJBA== X-Google-Smtp-Source: AH8x224+YpeT2stLJTyNv06+sTd1QPPXMIh5daKXXse9TmYjA9SA4nhFlBSBRUDVgRm0/FvebT7ptg== X-Received: by 10.31.229.66 with SMTP id c63mr6479717vkh.91.1518466276594; Mon, 12 Feb 2018 12:11:16 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.120.9 with SMTP id t9ls7880358vkc.13.gmail; Mon, 12 Feb 2018 12:11:15 -0800 (PST) X-Received: by 10.31.49.86 with SMTP id x83mr1147915vkx.0.1518466274987; Mon, 12 Feb 2018 12:11:14 -0800 (PST) In-Reply-To: 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:36890 Archived-At: ------=_Part_1121_1201974013.1518466274401 Content-Type: multipart/alternative; boundary="----=_Part_1122_2022522906.1518466274402" ------=_Part_1122_2022522906.1518466274402 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 call= to=20 >>>>> "operator..." of std::string_processing ). >>>>> >>>>> And then, with only c++17 metaprogramming capabilities, you could als= o=20 >>>>> 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 callable= =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 ha= s=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 a= s 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. And= =20 >>>> that's important if you do want to use template metaprogramming on str= ing=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 i= t=20 >>> 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 you= '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 ap= ply=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 "stri= ng=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 not= =20 allow the user to decide which kind of stream to use and therefore which=20 resulting string type to build? You can't do that with a UDL; they can't take an extra template parameter.= =20 `std::concat` can. However more "natural" the UDL version *appears*, it's ultimately much more= =20 limiting to *use*. And while appearance is important, usability ought to be= =20 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. 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. And= =20 even then, you shouldn't have to `using namespace blah` to be able to use= =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/41b87b07-1a91-4bca-ba00-5734c09dbe77%40isocpp.or= g. ------=_Part_1122_2022522906.1518466274402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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=A9cri= t=C2=A0:
On Monday,= February 12, 2018 at 11:15:33 AM UTC-5, floria...@gmail.com wrote:<= /div>
=
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_proce= ssing ).

And then, with only c++17 metaprogramming= capabilities, you could also use std::apply.
<= div>
You cannot `apply` things to operators. Not without creating a lamb= da 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 i= s, it's a lot easier in C++ as it currently stands to go from pa= rameter pack of values to an object than it is to go from an object to a pa= rameter 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.
<= /div>
=C2=A0
You have a point.

<= /div>
UDL the aggregate is not important to me, but it was easy to inclu= de and allows neat syntax (in my opinion).

B= ut it makes it impossible to apply a UDL to the string fragments. And that&= #39;s important if you do want to use template metaprogramming on string li= terals.

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&q= uot;sv;= // s i= s a string view
We are not interested in what is happening in the middle. I don't w= hy it should be different with string interpolation (or whatever the name i= s).

Because not all of the "liter= al" is actually a literal anymore. That's the whole point of strin= g interpolation: you're taking a literal and you're augmenting it w= ith some non-literal data. Potentially runtime non-literal data. It = isn't a literal anymore, so the UDL suffix can't apply to the aggre= gate. It can only apply to the individual literal fragments of the string.<= br>

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

And I would prefer co= ncatenate 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 `std::conc= at` would look like. It creates an `ostringstream`, applies it to each para= meter, and moves its result out. Why pick `ostringstream`? Why not allow th= e user to decide which kind of stream to use and therefore which resulting = string type to build?

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

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

You can't even do this in a header= :

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

That's due to having to `u= sing namespace` the literals before you can use them. Calling a function di= rectly requires no such gymnastics.

Oh sure, modules will (thankfull= y) remedy this situation to a degree. But until everyone's codebase is = modularized, that's going to be a problem. And even then, you shouldn&#= 39;t have to `using namespace blah` to be able to use 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/41b87b07-1a91-4bca-ba00-5734c09dbe77= %40isocpp.org.
------=_Part_1122_2022522906.1518466274402-- ------=_Part_1121_1201974013.1518466274401-- .