220 36815 <2806d759-b4b1-4e8a-8ed4-9d4fdf4844a1@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: Thu, 8 Feb 2018 19:38:05 -0800 (PST) Lines: 194 Approved: news@gmane.org Message-ID: <2806d759-b4b1-4e8a-8ed4-9d4fdf4844a1@isocpp.org> References: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4088_1261355947.1518147486041" X-Trace: blaine.gmane.org 1518147378 6753 195.159.176.226 (9 Feb 2018 03:36:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Feb 2018 03:36:18 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBH5P6TJQKGQEAYHRRKQ@isocpp.org Fri Feb 09 04:36:13 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ejzTn-0000tA-MV for gclcip-std-proposals@m.gmane.org; Fri, 09 Feb 2018 04:36:03 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id z11sf4083430uaz.0 for ; Thu, 08 Feb 2018 19:38:09 -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=sxyWKnuGw3lJ77z89drQsIOFLftDMrPa8PBRK64b+B4=; b=Qi0c+RuOzK0hxY9Sx2paq8WIzcJhAp3u2h9zwjm0PBvKOz4IaLezEnzx3bsGW0GMUn 4znZXBXhM/Er5/6jEs3Xs7kgwYU/bs3ss0HiCOdzfHEJ4BaZgcIaQbreSWmeMg7E/KTa 9siIQXC5fiby/yk8TkTaLONNH3NnH54PUyeogDAwbOkIVNx1Yq5YzJb6LLLRHma6IxWX p3CSp1CmWIxV54nkp+by3dGxDGoRbFPYWeTJcdXSDeGlMkUCi8G3kKuYMs9+mgVHcHoz mYVGq2uiTnMPnLgG/EbwlxXqZ8mwvmi/5wiu+Ce8ziouJdReASTtzmnOPwe9F1acubSZ WKcA== 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=sxyWKnuGw3lJ77z89drQsIOFLftDMrPa8PBRK64b+B4=; b=pw/5EWKYk9VrXnhD662DNgVGhFurdFxvm0F9Y4NO3hyFEfQKH2ayMRmt9FcuMDgNeD 2/V+Ic+KSeFgIQv1npJU+iHoACd6KRqtA1msJKTeWCnGhB/tJvQ1lj4YEAhWU+cVNppw DRREn5x20DqwbUu7qjueRmM3een8B+j8mp0Q3mvhtKwsAUvieFwstScaQ3srGDZUEeYZ qD7Z0UFnwoCyrRb9Tf9vVEOtCN/klxrEpkGRODzZWXmJHVf2CJvV+44h34wiSbacP3F+ 13Ge++pCueF5I2vEHFFiO/052p2rbVwxWkoeEOWlutDQ0VbH0tVcoZX4azTs02+ikCOK /GjQ== 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=sxyWKnuGw3lJ77z89drQsIOFLftDMrPa8PBRK64b+B4=; b=A+8Xy6mQ78ydY2nVIohEQL3qlYSU441Ww61XsPrTID9ckrA/ImWrDL/gt9vHW8CWmQ sjo7uyGTk6YEqkHc5piuDNr0VhL107axHXVJSE8LLW5Exj9cD06pFqHPtEaZ7QHiPSGJ aeGVj0XjcV2Rec5tpumuQ6ynQAFafcGdDNtLrFbN0gTkO1jVWpI+eCUqVkiiUVKLMxib 3QUAWxuRuwc4fkl5HRWlSnrqJFR6bT5ABUFk84f2uuprIgACRgIiEzt9UpeYsD/4YARi mzqs/SkzfVYCSwb4ryovCh/PQ/uZgvsMm9F1c+sPdoOz5HwZrrcyg9uKemclHoENe7gv XvTw== X-Gm-Message-State: APf1xPAC8i//qQXz4pNJo1IEjZHT1W+gThZal4PZRFsOzbUtlIl1VyRt myKRnSIXRcg5Ng1QqZQGDjJWFg== X-Google-Smtp-Source: AH8x225EldmP/ME6kn9sF5TezkXuhI62R3Gyc++YTOmDJD6DvxXT5NNOKWRs4obIHT9pGHGHmL+0Gg== X-Received: by 10.31.120.6 with SMTP id t6mr697458vkc.0.1518147488653; Thu, 08 Feb 2018 19:38:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.95.142 with SMTP id t136ls3273198vkb.20.gmail; Thu, 08 Feb 2018 19:38:06 -0800 (PST) X-Received: by 10.31.136.139 with SMTP id k133mr141888vkd.8.1518147486692; Thu, 08 Feb 2018 19:38:06 -0800 (PST) In-Reply-To: <356d5835-f1bf-4699-94f5-0b2d3d0b9c0e@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:36815 Archived-At: ------=_Part_4088_1261355947.1518147486041 Content-Type: multipart/alternative; boundary="----=_Part_4089_2121902617.1518147486044" ------=_Part_4089_2121902617.1518147486044 Content-Type: text/plain; charset="UTF-8" On Thursday, February 8, 2018 at 8:41:17 PM UTC-5, Jake Arkinstall wrote: > > T recipient; > // operator<<(std::ostream&, T) defined, or we naturally get an undefined > operator<< error later on > > string message = $"Hello, ${recipient}!" > > // becomes, internally, equivalent to: > // string message; > // { > // std::stringstream TMP_; > // TMP_ << "Hello " << recipient << "!"; > // message = TMP_.str() > // } > > std::cout << $"The message is ${message}\n"; > > // becomes, internally, equivalent to: > // { > // std::cout << "The message is " << message << "\n"; > // } > // // braces not really necessary, but it makes generalisation easier: > // // Trade a dollar for a pair of braces every time. > // > // // If we REALLY don't care about performance, this could use the > // // string approach and send the resulting string to std::cout. *shudder* > > This is designed to be a gentler, quick-and-easy way of using streams, not > the most flexible nor the fastest approach; obviously, if you want speed > and flexibility, you're often going to have to do things the long way > around. But if you don't want that, and just want to get that code down as > quickly as possible before future optimisations, I think this approach has > merit. > And that is precisely the flaw in your proposal. 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. When you're building library components, it's OK to make a library-based system that perhaps has some deficiencies in performance in order to allow it to be easier to use (note: this does not excuse iostreams). When you're building something into the *language*, you can't just do that. Language features should not generate bad code by default. And I submit that the above is bad code. Or at the very least, it could very easily be better code if it didn't use a terrible system like iostream. 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. 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. 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. 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. -- 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/2806d759-b4b1-4e8a-8ed4-9d4fdf4844a1%40isocpp.org. ------=_Part_4089_2121902617.1518147486044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, February 8, 2018 at 8:41:17 PM UTC-5, Jake Ar= kinstall wrote:
T recipient;
// operator<<(std::os= tream&, T) defined, or we naturally get an undefined operator<< e= rror later on

string message =3D $"Hello, ${recipient}!"

// becomes, internal= ly, equivalent to:
// string message;
// {
// =C2=A0 =C2=A0 std::stringstream TMP_;
// =C2= =A0 =C2=A0 TMP_ << "Hello " << recipient << &qu= ot;!";
// =C2=A0 =C2=A0 message =3D TMP_.str()
// }

std::cout << $"The message is= ${message}\n";

// becomes, internal= ly, equivalent to:
// {
// =C2=A0 =C2=A0 std::cout << "The message is &= quot; << message << "\n";
// }
// // braces not really necess= ary, but it makes generalisation easier:<= br>// // Trade a dollar for a pair of bra= ces every time.
//
// // If we REALLY don't care about performance, this could = use the
// // string approach and send the resulting string to std::cout. *shud= der*

Thi= s is designed to be a gentler, quick-and-easy way of using streams, not the= most flexible nor the fastest approach; obviously, if you want speed and f= lexibility, you're often going to have to do things the long way around= .. But if you don't want that, and just want to get that code down as qu= ickly as possible before future optimisations, I think this approach has me= rit.

And that is precisely the flaw in your prop= osal. 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.

When you're building library= components, it's OK to make a library-based system that perhaps has so= me deficiencies in performance in order to allow it to be easier to use (no= te: this does not excuse iostreams). When you're building something int= o the language, you can't just do that. Language features should= not generate bad code by default. And I submit that the above is bad code.= Or at the very least, it could very easily be better code if it didn't= use a terrible system like iostream.

See, the problem is that iostr= eam is: 1) the only extensible, type-safe formatting system available to st= andard C++, and 2) terrible in pretty much every other way.

If you w= ant to incorporate something like this into the language, then you first= needs to come up with an underlying model which isn't terrible. Th= at is, an extensible, type-safe system for converting objects to strings. A= nd there's absolutely no excuse for this not being `constexpr` aware. I= t should not be based on virtual functions.

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

If "string interpolation" is to be worthwhile, I shouldn&= #39;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.

--
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/2806d759-b4b1-4e8a-8ed4-9d4fdf4844a1= %40isocpp.org.
------=_Part_4089_2121902617.1518147486044-- ------=_Part_4088_1261355947.1518147486041-- .