220 36819 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: String interpolation Date: Thu, 8 Feb 2018 23:50:33 -0800 (PST) Lines: 364 Approved: news@gmane.org Message-ID: References: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@isocpp.org> <2806d759-b4b1-4e8a-8ed4-9d4fdf4844a1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4338_1994671980.1518162633154" X-Trace: blaine.gmane.org 1518162543 21373 195.159.176.226 (9 Feb 2018 07:49:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 07:49:03 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBSVF6XJQKGQEKDQVYRY@isocpp.org Fri Feb 09 08:48:59 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ek3Q6-0003gj-DS for gclcip-std-proposals@m.gmane.org; Fri, 09 Feb 2018 08:48:30 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id b195sf3774895vkf.8 for ; Thu, 08 Feb 2018 23:50:36 -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=ABETWqOyE/V+B7VY0ggKEtVGOvbC+PF74OifXdhQEDs=; b=vXstTwzXO32DEk5OfPGSw5/nVKJh4QbpKGUG5BC6rIqn+WsHDWKT+J2ebHMd++huj6 9/Kg5nELpiCchHLcISivUTEi0uPtZp6L8gzqGIbOmIksWmjmmshBqbeDjim15b+Ju75g nVy59gXMG69vEZLmTjRRZkDLvsD8epEHB7Q2AdNe+AgJYnUZt3hRYfaR4lNuM6NkGI9O X5YRkBsLXgA4nTZNNsxzfyCki6SsP49YSTFC0+7QoRE0NiP8pbqidox2QBEVabk9O64K +n82znBJDIgVG5jLJ2HyESYynYe4NA06+kZwc59/tKNz3ExuWI14p10qDoX68qysGKwS coIg== 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=ABETWqOyE/V+B7VY0ggKEtVGOvbC+PF74OifXdhQEDs=; b=KAoUM5/UJaTFpJMHv/53tzg3LVdluzOqPAeeGQ2jqrKqMuN1Nftdp+1PUUaCKB6fjX ebNBld2MS1l6YMKGciX3hCCSR20SBr/o00kqzKWT89FetESvY48jz1MvLOb/bETc0gwP KWH5AzKP94DHFMhI35B2MFIVWrpR3JS0oJQIHq2UgSHLiA0vYiBN64AR0u0aWzVgRJ2b Y1zlltiM6CMKM7mn9LpRDKsw6u7w0MUrChxOZ5p5MDy3YlaaKj3qRlLt+cgZtmck1hnM v2JXL2g1134SlmpW37pH3qw/wYXwVkDaejTGm01IFjQtJcDr2kUUGUevix8XRwVi6vfH hULg== 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=ABETWqOyE/V+B7VY0ggKEtVGOvbC+PF74OifXdhQEDs=; b=eR9GPW5uszda8BLP9c+W7DwY3AVqNUvJFPGNfcOS2eymnYLEE6SWggCjb6y0pbPzka Ff/4ugwk0Gpip14hZWj8f41hJBm2ylX/3uRCF9NwFTXP0i/mdz5Do1xCh8YUmu3GITAW 01b88B2FtkCY/ZP4Im/jRecJaWaASpk7EBIl4YjmYMR75juFCfOEYyV21geTe8V6ImQH Hch3Y04gRxctjQNpKyR4X/uXnojnsHSlbG5H1oKzcUx4qVi+SpkBKsfCvYUKIzSFDtGc lGRbqkZR4lHKumprpD7YujOlGTDFlBaOF4hMNHAO/pZqYZ6NFBgrotIez5gjEii0rvsm hbzA== X-Gm-Message-State: APf1xPCyNB46SJQDulIEUC0Bg/7NgY7rzIihjW5ia7lPi+jWlS4qTxzN Lvwzcl61EBTvDI1uNTVSRqTBPQ== X-Google-Smtp-Source: AH8x2243OT7+BDFaQ24jtSvYDx/h84iFhUARyM2Zs/T3xSOvru5/amIGJ3rWsH1M7gvDkRUICqhlZQ== X-Received: by 10.176.83.41 with SMTP id x38mr941204uax.117.1518162635470; Thu, 08 Feb 2018 23:50:35 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.169.142 with SMTP id s136ls3744925vke.18.gmail; Thu, 08 Feb 2018 23:50:33 -0800 (PST) X-Received: by 10.31.169.23 with SMTP id s23mr193689vke.1.1518162633792; Thu, 08 Feb 2018 23:50:33 -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:36819 Archived-At: ------=_Part_4338_1994671980.1518162633154 Content-Type: multipart/alternative; boundary="----=_Part_4339_68324471.1518162633154" ------=_Part_4339_68324471.1518162633154 Content-Type: text/plain; charset="UTF-8" On Friday, February 9, 2018 at 1:06:40 AM UTC-5, Jake Arkinstall wrote: > > On 9 Feb 2018 03:38, "Nicol Bolas" > > wrote: > > There is no reason why I should have to choose between "slow and > convenient" and "fast and hard-to-use". The evolution of modern C++ has > been to take "fast and hard-to-use" and turn it into "fast and > easy-to-use". `constexpr` makes an entire branch of template > metaprogramming look like normal code. Variadic templates make many things > that were out of reach for the average programmer into much easier > metaprogramming techniques. Concepts take the `enable_if` hack and makes it > into a real, extensible part of the language. And so forth. > > > The conflict I am facing is that (a) C++ handling of injecting variables > into strings is a choice of ugly, ugly, or ugly, and (b) there is no > efficient way (that I can think of) of changing that. > There is an efficient way. There are plenty of better solutions than using `iostreams` for string formatting. They may not be part of the standard library yet, but there have been proposals for some of them . But there are situations, as I set out in the beginning, where (a) takes > priority over (b). It is not everyone's cup of tea, granted. > Show me another C++ language feature that is fundamentally rooted in doing things the slow way. Other than exceptions. Or things related to virtual functions/dynamic_casting of multiple inheritance. Here's the thing. `iostreams`, for all of its failures, is ephemeral. It can be replaced; it can go away. A language feature cannot just "go away". If we add a better way of doing text formatting, then "string interpolation" will not be able to use it, unless it can be made to do so in a backwards compatible way. That's bad. Language features *have to* get it right the first time. Just look at "uniform initialization" to see what happens when you screw that up. See, the problem is that iostream is: 1) the only extensible, type-safe > formatting system available to standard C++, and 2) terrible in pretty much > every other way. > > > iostream is what we have, iostream is the de-facto approach that most > people use when outputting a variety of objects in non-time-critical code. > The fact is that people are *already* using them, they already have their > stream operators defined for built-in types and for any kind of custom type > that is supposed to be output in the first place. All this does is make > their lives easier in doing so. This is the reason I chose this approach - > it gives people a smoother way of doing what they are already doing without > all the fuss of adding in other code. > > > If you want to incorporate something like this into the language, then you > *first* needs to come up with an underlying model which isn't terrible. > That is, an extensible, type-safe system for converting objects to strings. > And there's absolutely no excuse for this not being `constexpr` aware. It > should not be based on virtual functions. > > > Converting objects to strings and then doing what? That's the problem. We > could always use a typecast to string (in many-member objects these methods > often end up using stringstreams in the first place) then concatenating the > result to the preceding literal, followed by further concatenations. Copies > everywhere. We could come up with a mechanism by which the result is > sequentially added to the existing string, but that's iostream in a > nutshell. > It is? `iostream` is rooted in virtual calls. I see nothing about "a mechanism by which the result is sequentially added to the existing string" that *requires* virtual calls. That's a design choice, not a fundamental requirement. Introducing something new would be a much bigger change, and requires > convincing the community to change their habits and legacy code. Syntactic > sugar is not worth all that. > But "all that" is worthwhile in and of itself. Getting a better string formatting system would be a great proposal; adding "string interpolation" to that would merely be icing on the cake. I'm aiming for something that is *less* demanding on the user. > > I will see if I can find out how it is implemented in the other languages > and report back. I cannot imagine that they use anything that is > inaccessible to us, but instead I believe that they are just more accepting > of the small cost involved. > > Once you have that, then you can go about suggesting using that as the > basis for "string interpolation". But what you're doing is putting the cart > before the horse. Or at the very least, asking a cart to be driven by a > very lame horse. > > > A very lame horse that is trusty enough to pull the community thus far, > If that were truly the case, why do we have `to/from_chars`? No, "the community" has needed a replacement for iostreams for a long time. We simply don't have one at present. and a cart that is used extensively in other (ditching the metaphor here) > languages because it is incredibly easy to use. > > If "string interpolation" is to be worthwhile, I shouldn't have to think > about whether it's performant enough to use it in my code. Just like I > don't have to worry that range-based `for` loops will copy values into a > temporary `vector` or something before iterating over them. > > > Ideally, this would be nice. If you can think of such a thing, here is the > perfect place to discuss it. My focus here is very much on the cart. As for > the horse, I don't much have a preference, except that ease of use is vital. > If the options are "no string interpolation" and "bad string interpolation", I'll take the former over the latter. Better to have no feature than to have one that you have to think about whether it's reasonable to use it when it is otherwise entirely appropriate. Again, look to my range-based `for` analogy; that syntactic sugar doesn't get in the way. But I find it damaging for us to refuse to have nice things simply based on > one metric - there are multiple costs involved in a project, and > development time and ease of use is one of them. Creating a way of making > things easier on developers in the times that they aren't looking for the > fastest solution is useful in that regard. > Why do you assume that a non-iostreams solution would not have "ease of use"? Your entire argument is predicated on the notion that you have to choose between "easy to use" and "fast". Take P0645, mentioned above. Its customization point is a non-member function, just like iostream, which will be looked up through ADL. The only real difference between it and iostream (besides the performance) is that the function isn't named `operator<<`. There is nothing about this which is particularly difficult to use. Just because iostreams exists today doesn't mean that there's not a better solution that would be no more difficult to use than that. Of course, the question would then be why they are using C++ in the first > place. But it would be wrong to suggest that 100% of the time that you're > writing C++ you're thinking purely about the performance of each run, > especially during a debug session or in the early stages as I mentioned. > And, for your layman who isn't concerned about the cost of building a > string in an iostream and copying the result to a string - from beginners, > to people who are testing out an idea, or demonstrating functionality, > doing old-school debugging, or who just aren't concerned about performance > at that stage - it costs them nothing, but gives them a nicer language to > work with. > > There may be an alternative, and that's improved and standardised > preprocessor functionality so that people can have more flexibility. The > fact that we can't even have control of state, e.g. defines inside macros, > is extremely limiting (otherwise this would be doable in some form via > macros). I guess it is perfectly possible to make a pre-preprocessor to run > the code through pre-translation, but that adds its own complications. > -- 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/d404b982-04e5-4520-8384-25632af83d96%40isocpp.org. ------=_Part_4339_68324471.1518162633154 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, February 9, 2018 at 1:06:40 AM UTC-5, Jake Arki= nstall wrote:
On 9 Feb 2018 03:38, "Ni= col Bolas" <jmck...@gmail.com> wrote:
There is no reason why I should have to choose = between "slow and=20 convenient" and "fast and hard-to-use". The evolution of mod= ern C++ has=20 been to take "fast and hard-to-use" and turn it into "fast a= nd=20 easy-to-use". `constexpr` makes an entire branch of template=20 metaprogramming look like normal code. Variadic templates make many=20 things that were out of reach for the average programmer into much easier m= etaprogramming techniques.=20 Concepts take the `enable_if` hack and makes it into a real, extensible=20 part of the language. And so forth.

The conflict I am facing is = that (a) C++ handling of injecting variables into strings is a choice of ug= ly, ugly, or ugly, and (b) there is no efficient way (that I can think of) = of changing that.

There is an efficient wa= y. There are plenty of better solutions than using `iostreams` for string f= ormatting. They may not be part of the standard library yet, but there have been proposals for some of them.

But there a= re situations, as I set out in the beginning, where (a) takes priority over= (b). It is not everyone's cup of tea, granted.

Show me another C++ language feature that is fundamentally rooted= in doing things the slow way. Other than exceptions. Or things related to = virtual functions/dynamic_casting of multiple inheritance.

Here'= s the thing. `iostreams`, for all of its failures, is ephemeral. It can be = replaced; it can go away. A language feature cannot just "go away"= ;. If we add a better way of doing text formatting, then "string inter= polation" will not be able to use it, unless it can be made to do so i= n a backwards compatible way.

That's bad. Language features h= ave to get it right the first time. Just look at "uniform initiali= zation" to see what happens when you screw that up.

See, the problem is that iostream is: 1) the only extens= ible, type-safe formatting system available to standard C++, and 2) terribl= e in pretty much every other way.
<= div dir=3D"auto">
iostream is what we have, iost= ream is the de-facto approach that most people use when outputting a variet= y of objects in non-time-critical code. The fact is that people are alre= ady using them, they already have their stream operators defined for bu= ilt-in types and for any kind of custom type that is supposed to be output = in the first place. All this does is make their lives easier in doing so. T= his is the reason I chose this approach - it gives people a smoother way of= doing what they are already doing without all the fuss of adding in other = code.
=C2=A0
If you want to incorporate someth= ing like this into the language, then you first needs to come up wit= h an underlying model which isn't terrible. That is, an extensible, typ= e-safe system for converting objects to strings. And there's absolutely= no excuse for this not being `constexpr` aware. It should not be based on = virtual functions.

Converting objects to strings and then doing = what? That's the problem. We could always use a typecast to string (in = many-member objects these methods often end up using stringstreams in the f= irst place) then concatenating the result to the preceding literal, followe= d by further concatenations. Copies everywhere. We could come up with a mec= hanism by which the result is sequentially added to the existing string, bu= t that's iostream in a nutshell.

It is= ? `iostream` is rooted in virtual calls. I see nothing about "a mechan= ism by which the result is sequentially added to the existing string" = that requires virtual calls. That's a design choice, not a funda= mental requirement.

Introducing something new would be a= much bigger change, and requires convincing the community to change their = habits and legacy code. Syntactic sugar is not worth all that.
<= /blockquote>

But "all that" is worthwhile in and of itsel= f. Getting a better string formatting system would be a great proposal; add= ing "string interpolation" to that would merely be icing on the c= ake.

I'm aiming for something that is less de= manding on the user.

I w= ill see if I can find out how it is implemented in the other languages and = report back. I cannot imagine that they use anything that is inaccessible t= o us, but instead I believe that they are just more accepting of the small = cost involved.

Once you have that, then y= ou can go about suggesting using that as the basis for "string interpo= lation". But what you're doing is putting the cart before the hors= e. Or at the very least, asking a cart to be driven by a very lame horse.

A very lame horse that is trusty enough to pull the community thus fa= r,

If that were truly the case, why do we = have `to/from_chars`? No, "the community" has needed a replacemen= t for iostreams for a long time. We simply don't have one at present.
=
and a cart that is used extensively in other (ditching th= e metaphor here) languages because it is incredibly easy to use.

If "string interpolati= on" is to be worthwhile, I shouldn't have to think about whether it's performant enough to use it in my code. Just like I= don't have to worry that range-based `for` loops will copy values into= a temporary `vector` or something before iterating over them.

I= deally, this would be nice. If you can think of such a thing, here is the p= erfect place to discuss it. My focus here is very much on the cart. As for = the horse, I don't much have a preference, except that ease of use is v= ital.

If the options are "no string i= nterpolation" and "bad string interpolation", I'll take = the former over the latter. Better to have no feature than to have one that= you have to think about whether it's reasonable to use it when it is o= therwise entirely appropriate. Again, look to my range-based `for` analogy;= that syntactic sugar doesn't get in the way.

=
But I find it damaging for us to refuse to have nice thin= gs simply based on one metric - there are multiple costs involved in a proj= ect, and development time and ease of use is one of them. Creating a way of= making things easier on developers in the times that they aren't looki= ng for the fastest solution is useful in that regard.

Why do you assume that a non-iostreams solution would not have = "ease of use"? Your entire argument is predicated on the notion t= hat you have to choose between "easy to use" and "fast"= ..

Take P0645, mentioned above. Its customization point is a non-memb= er function, just like iostream, which will be looked up through ADL. The o= nly real difference between it and iostream (besides the performance) is th= at the function isn't named `operator<<`. There is nothing about = this which is particularly difficult to use.

Just because iostreams = exists today doesn't mean that there's not a better solution that w= ould be no more difficult to use than that.

Of course, = the question would then be why they are using C++ in the first place. But i= t would be wrong to suggest that 100% of the time that you're writing C= ++ you're thinking purely about the performance of each run, especially= during a debug session or in the early stages as I mentioned. And, for you= r layman who isn't concerned about the cost of building a string in an = iostream and copying the result to a string - from beginners, to people who= are testing out an idea, or demonstrating functionality, doing old-school = debugging, or who just aren't concerned about performance at that stage= - it costs them nothing, but gives them a nicer language to work with.

There may be an alternative= , and that's improved and standardised preprocessor functionality so th= at people can have more flexibility. The fact that we can't even have c= ontrol of state, e.g. defines inside macros, is extremely limiting (otherwi= se this would be doable in some form via macros). I guess it is perfectly p= ossible to make a pre-preprocessor to run the code through pre-translation,= but that adds its own complications.

--
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/d404b982-04e5-4520-8384-25632af83d96= %40isocpp.org.
------=_Part_4339_68324471.1518162633154-- ------=_Part_4338_1994671980.1518162633154-- .