220 36886 <0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549@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 08:56:48 -0800 (PST) Lines: 350 Approved: news@gmane.org Message-ID: <0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_9675_1179020735.1518454608528" X-Trace: blaine.gmane.org 1518454502 31114 195.159.176.226 (12 Feb 2018 16:55:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 16:55:02 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBUMOQ7KAKGQE37HWFFA@isocpp.org Mon Feb 12 17:54:57 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 1elHNN-00072j-68 for gclcip-std-proposals@m.gmane.org; Mon, 12 Feb 2018 17:54:45 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id c17sf9457012vke.1 for ; Mon, 12 Feb 2018 08:56:51 -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=kqlZ3BHd33nVg5KmsZso1bW2c99ouZBF9y5jBO6USHU=; b=iG1kcOjnpnEGYPm9LgIAqMP9+BJ9tNMi69kEpTXIUlfirq+sIPxXLEv3Qz7Q08ny7r N/EYINHjBPsdOp+OHX2KcKetkVLlJ7ORwJPN5Dc96GuC/D+902WTFMS/+apCPIfqsi4m MdlahmA/nuhN6hEAJF89Vzvf5JI+F3pxCTcCsy3Vl0LjgjzGQK3mHAkPBzKh4ReRPwNA chjGAh/JmZfLj1jL3oRhi4Go7PFungDANWaX5sIMd6W1PrVyO6NRnp5U12SJmiXXhhWQ qwhpH4HJJXhtQGwrwoQ78iYurCN9zErqBoqNyFY/E8UpHr/DBhSct7KeyG1Yn4M3qwLf R1SA== 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=kqlZ3BHd33nVg5KmsZso1bW2c99ouZBF9y5jBO6USHU=; b=V7lexZoL3OzcLJQEFtcjpoqGCYb+vtEa2YOg3817COdffOPB7oL0VNK+6ZyY+P1m87 8wAqnSa/Y9RhvbSoKqb3G0adyEioM18FLFz28CMek0xAzUk+308vjxy/O2FWydK6z5fP edpGKIFFKWLhF9dOP/8H/9Sp3M/IzC/pK73hoAWEbG8SQIg8vAMUwQKVWanyh4YBIYM4 sJNH0j5KdsD+QsZJ65sJ89lHHQ+eklvYH0zSf/iUr5kTisrNCR+mQ2xMkzHkP7upwPN2 mB6H/OzgJdoilPKf9tgE7kl3Zn7I1VPk19Jf3ByX8gjWWk4dcmgLy0Pct1mpQelBKf52 6idA== 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=kqlZ3BHd33nVg5KmsZso1bW2c99ouZBF9y5jBO6USHU=; b=ciIXlpvofLwqYP9zWY3Mo9R+d2Ta0+4uQr2SyVJNU5a/rOVTwxfTqMXlIQZoSXiUuY oUKbRHfxBeXl4OhK1HyQWLXtG0wg86aQwJas79GZ/sHDjScMD4CUzQ/VBWVXKHzAxs1d DugEM8e9m7sVzwEi31TlL3VP5DwJkIVTIFWYPqj+ZIusbI7kv5QIdyB9wcMQcBpIRzEe exqChf5TsCcLwQxgnTVnj+4+HNirpVnAiD8H3T5uLHzDHJdQGGI76d0t8iD0UMDFm5Nx hQCa6PVg7wL8CJI0xAt65l3Zps3TvfM4sxbI8uYNNzl/5IdMVq+uiv9onIy1TuHafsbp zmzQ== X-Gm-Message-State: APf1xPBT2YqO1zyFv7N3vrB+wu9hzv0WbrAhvwuBWmDt+i2CPZEdG7GI R7IZLiUEQD4nqQ9uG2wc+H8nVA== X-Google-Smtp-Source: AH8x224dj6GxAAuSP7J//+RAs9h5TxpZldu8HKkXmzYBK7kN62XB515kNsqJ43FQ3dQSxewyVzlYTw== X-Received: by 10.31.135.16 with SMTP id j16mr6338681vkd.67.1518454610684; Mon, 12 Feb 2018 08:56:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.178.134 with SMTP id b128ls7271830vkf.7.gmail; Mon, 12 Feb 2018 08:56:49 -0800 (PST) X-Received: by 10.31.128.137 with SMTP id b131mr1092448vkd.7.1518454609059; Mon, 12 Feb 2018 08:56:49 -0800 (PST) In-Reply-To: <305b7669-0744-473e-9715-807b7e8051b6@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:36886 Archived-At: ------=_Part_9675_1179020735.1518454608528 Content-Type: multipart/alternative; boundary="----=_Part_9676_1456959997.1518454608528" ------=_Part_9676_1456959997.1518454608528 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Monday, February 12, 2018 at 11:15:33 AM UTC-5, floria...@gmail.com=20 wrote: > > Le lundi 12 f=C3=A9vrier 2018 16:45:41 UTC+1, Nicol Bolas a =C3=A9crit : >> >> And sadly, none of them have advanced or even received additional revise= d=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 value= s=20 >> around as a collective object. And if you did, you can make one triviall= y,=20 >> as above. >> >> And again, it still doesn't deal with the fact that you lose perfect=20 >> forwarding. >> > =20 > I understand your point about creating a tuple from a parameter pack to b= e=20 > able to do what is natural with my proposal. Fair enough. > > However, I don't see how we lose perfect forwarding. I mean, if the=20 > variable is a lvalue, it is stored as an lvalue reference, and if it is a= =20 > rvalue, it is stored as an rvalue reference. > This would be the exact same rules as for std::forward_as_tuple. > So what does `get` return? How do you use `get` such that it returns an=20 rvalue reference or lvalue reference appropriately? Also, by using `forward_as_tuple` for your basis of implementation, you=20 make something as simple as this: auto val =3D F"interpolate {5}"; Into a dangling reference. If we allow more than just variable names in=20 interpolation, then the expressions can be prvalues, and the lifetimes of= =20 any temporaries they manifest will work the way regular C++ works. Since=20 they're bound to the parameters of an object consturctor, their lifetimes= =20 end with the termination of the expression. So `val` will reference a=20 destroyed `int`. You'd have to start playing games like braced-init-lists do when they=20 manifest an `initializer_list` to fix this. I'd rather make that a straight-up error and force you to explicitly stick= =20 such things in a specific type. >> 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 t= o=20 >>> "operator..." of std::string_processing ). >>> >>> And then, with only c++17 metaprogramming capabilities, you could also= =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. Remember:= =20 the whole idea is that you're dealing with a sequence of variables of=20 different types. So the second parameter to the operator has to be of=20 different types for different invocations of the operator. 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 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 strin= g=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 it= =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 the= =20 whole point of string interpolation: you're taking a literal and you're=20 augmenting it with some non-literal data. Potentially *runtime* non-literal= =20 data. It isn't a literal anymore, so the UDL suffix can't apply to the=20 aggregate. It can only apply to the individual literal fragments of the=20 string. Also, remember: you cannot apply a UDL suffix to a `constexpr` string=20 value. So again, if we ever want to apply interpolation to `constexpr`=20 strings, then we need to have an invocation syntax that doesn't encourage= =20 people to use UDLs for them. And with my proposal, you can always apply a function to every single=20 > element, and this function can be a UDL if you really want. > > > To sum up, F"something" returning a parameter pack is probably the way to= =20 > go because of the current C++, but would not bring that much with a prope= r=20 > C++. > I don't agree with that. Even if we had P0535, it's still easier to work=20 with the arguments as a pack than it is to turn an object into a pack.=20 P0535 lowers the bar into the "reasonable" range, but 9 times out of 10,=20 just taking the parameters as a pack rather than unpacking an object will= =20 be easier. Using a pack also handily deals with the lifetime issues for prvalues, if= =20 we allow arbitrary expressions in interpolated strings. Also, let's not forget the other things I mentioned. That=20 `string_processing` would have to be a magic type created only by the=20 compiler like `initializer_list`. Which means you cannot call one of the=20 aggregation functions with your own parameters; they would be explicitly=20 bound to using string interpolation. By contrast, if you're just using=20 regular functions with variadic arguments, you can call them yourself=20 without invoking string interpolation. That makes my version more flexible. And then, I think UDL should apply to the whole stuff and not its part. > So how do you apply a UDL to just the string literal fragments? Without=20 creating a bunch of pointless variables, which is the antithesis of the=20 whole idea of interpolation. The point of that discussion was a comment someone made about doing=20 template metaprogramming on string literals. To do that, you need a way to= =20 access each literal as a distinct type, some `string_literal` type. And only a UDL applied to each fragment can perform= =20 that kind of synthesis. --=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/0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549%40isocpp.or= g. ------=_Part_9676_1456959997.1518454608528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, February 12, 2018 at 11:15:33 AM UTC-5, floria.= ...@gmail.com wrote:
Le lundi 12 f=C3=A9vrier 2018 16:45:41 UTC+1, Nicol Bolas a =C3=A9cri= t=C2=A0:
And sadly,= none of them have advanced or even received additional revised proposals. = My way works just fine with C++ as it is.

And even if we had th= at, most use-cases you don't need to pass the values around as a collec= tive object. And if you did, you can make one trivially, as above.

A= nd again, it still doesn't deal with the fact that you lose perfect for= warding.
=C2=A0
I understand you= r point about creating a tuple from a parameter pack to be able to do what = is natural with my proposal. Fair enough.

However,= I don't see how we lose perfect forwarding. I mean, if the variable is= a lvalue, it is stored as an lvalue reference, and if it is a rvalue, it i= s stored as an rvalue reference.
This would be the exact same rul= es as for std::forward_as_tuple.

So what d= oes `get` return? How do you use `get` such that it returns an rvalue refer= ence or lvalue reference appropriately?

Also, by using `forward_as_t= uple` for your basis of implementation, you make something as simple as thi= s:

auto va= l =3D F"interpolate {5}&q= uot;;

Into a dangling reference. If we allow more than j= ust variable names in interpolation, then the expressions can be prvalues, = and the lifetimes of any temporaries they manifest will work the way regula= r C++ works. Since they're bound to the parameters of an object constur= ctor, their lifetimes end with the termination of the expression. So `val` = will reference a destroyed `int`.

You'd have to start playing ga= mes like braced-init-lists do when they manifest an `initializer_list` to f= ix this.

I'd rather make that a straight-up error and force you = to explicitly stick such things in a specific type.


With that in mind, the impl= ementation of your concat function with my approach would be exactly the sa= me as with your approach (with a call to "operator..." of std::st= ring_processing ).

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

You cannot `apply` things to operators. Not without creat= ing a lambda 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 g= et the address of a single overload of an operator. Remember: the whole ide= a is that you're dealing with a sequence of variables of different type= s. So the second parameter to the operator has to be of different types for= different invocations of the operator.

The fact is, it's a lot ea= sier in C++ as it currently stands to go from parameter pack of values to a= n object than it is to go from an object to a parameter pack of values. I w= ish 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 aggregat= e is not important to me, but it was easy to include and 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 literals.

I'm not sure to see the use case here. W= hen you use UDL, you want the whole literal to be what you say it would be.=
auto s =3D "something"s; // s is a stringauto = sv =3D = "some other"sv; // s is a string view=
We are not interes= ted in what is happening in the middle. I don't why it should be differ= ent with string interpolation (or whatever the name is).

Because not all of the "literal" is actually a= literal anymore. That's the whole point of string interpolation: you&#= 39;re taking a literal and you're augmenting it with some non-literal d= ata. Potentially runtime non-literal data. It isn't a literal an= ymore, so the UDL suffix can't apply to the aggregate. It can only appl= y to the individual literal fragments of the string.

Also, remember:= you cannot apply a UDL suffix to a `constexpr` string value. So again, if = we ever want to apply interpolation to `constexpr` strings, then we need to= have an invocation syntax that doesn't encourage people to use UDLs fo= r them.

And with my proposal, you can always ap= ply a function to every single element, and this function can be a UDL if y= ou really want.


To sum up, F"s= omething" returning a parameter pack is probably the way to go because= of the current C++, but would not bring that much with a proper C++.
=

I don't agree with that. Even if we had P05= 35, it's still easier to work with the arguments as a pack than it is t= o turn an object into a pack. P0535 lowers the bar into the "reasonabl= e" range, but 9 times out of 10, just taking the parameters as a pack = rather than unpacking an object will be easier.

Using a pack also ha= ndily deals with the lifetime issues for prvalues, if we allow arbitrary ex= pressions in interpolated strings.

Also, let's not forget the ot= her things I mentioned. That `string_processing` would have to be a magic t= ype created only by the compiler like `initializer_list`. Which means you c= annot call one of the aggregation functions with your own parameters; they = would be explicitly bound to using string interpolation. By contrast, if yo= u're just using regular functions with variadic arguments, you can call= them yourself without invoking string interpolation.

That makes my = version more flexible.

And then, I think UDL should apply to the whole= stuff and not its part.

So how do you app= ly a UDL to just the string literal fragments? Without creating a bunch of = pointless variables, which is the antithesis of the whole idea of interpola= tion.

The point of that discussion was a comment someone made abou= t doing template metaprogramming on string literals. To do that, you need a= way to access each literal as a distinct type, some `string_literal<cha= r, 'c', 'h', 'a', 'r'>` type. And only a= UDL applied to each fragment can perform that kind of synthesis.

--
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/0ceb2063-d7b6-4cb8-8c5c-c63aceb5b549= %40isocpp.org.
------=_Part_9676_1456959997.1518454608528-- ------=_Part_9675_1179020735.1518454608528-- .