220 20505 <55FD7DE6.2070203@gmail.com> article Path: news.gmane.org!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Rough Draft Proposal of Interpolated String Literals Date: Sat, 19 Sep 2015 17:23:18 +0200 Lines: 82 Approved: news@gmane.org Message-ID: <55FD7DE6.2070203@gmail.com> References: <55FC8A6B.1070100@gmail.com> <650f78b0-289e-4880-9c03-8615b25360ec@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed X-Trace: ger.gmane.org 1442676199 3641 80.91.229.3 (19 Sep 2015 15:23:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 19 Sep 2015 15:23:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBYH36WXQKGQENY5OJUI@isocpp.org Sat Sep 19 17:23:14 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f198.google.com ([209.85.212.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZdJys-00008t-1s for gclcip-std-proposals@m.gmane.org; Sat, 19 Sep 2015 17:23:14 +0200 Original-Received: by wicgb1 with SMTP id gb1sf18344249wic.3 for ; Sat, 19 Sep 2015 08:23:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=I/kp+8VMgP+sxBbNUlWWSqdJcQhxSADbzsCf5GvNJRE=; b=F19oF6KGkfmN/N+hMUfMDhdZgdF+m6sRrFAE/e0ttWHCaLP58f/7akiqpAuEmuCnKS 1sYRb9AoFgp9uHGHWWMlW0TKgPDkJlk/Q6aOmgJWbvWG24XRtqu/TFazA6HSIoNLUd4Y REYGLywHc+9C+z1q+KBjh6YX6zjAcs5Hirt8tEVTAUgjlVf8+kg2hR18Fsc0zSNFRPas 7U1vBSrycqd184n4pUlam5hYRoxioTGhNpymjPujzqIW5uuKl4K9fxF6jW7gbaXduNGB 2XqwXTBkU5UW9CSo8Ynf7HRPEtIUEM+KTIdEqIEQjn/kr6Cj2CT2K+DlQU3+fPLVmzpO 0v7A= X-Gm-Message-State: ALoCoQnx9ptBPrEJVwsAujWNwuIlLxgnljfYm3Ys04TyLOM57uiDRIpdF/tu9TVH8wMpk5dGZhxo X-Received: by 10.152.21.42 with SMTP id s10mr1819942lae.9.1442676193447; Sat, 19 Sep 2015 08:23:13 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.104.2 with SMTP id ga2ls359955wib.34.gmail; Sat, 19 Sep 2015 08:23:11 -0700 (PDT) X-Received: by 10.180.88.201 with SMTP id bi9mr3888635wib.21.1442676191923; Sat, 19 Sep 2015 08:23:11 -0700 (PDT) Original-Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com. [2a00:1450:400c:c05::22e]) by mx.google.com with ESMTPS id ub1si4772913wib.30.2015.09.19.08.23.11 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Sep 2015 08:23:11 -0700 (PDT) Received-SPF: pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c05::22e as permitted sender) client-ip=2a00:1450:400c:c05::22e; Original-Received: by wicge5 with SMTP id ge5so65532786wic.0 for ; Sat, 19 Sep 2015 08:23:11 -0700 (PDT) X-Received: by 10.194.71.206 with SMTP id x14mr14676481wju.147.1442676191690; Sat, 19 Sep 2015 08:23:11 -0700 (PDT) Original-Received: from [192.168.42.33] (ppp-93-104-178-103.dynamic.mnet-online.de. [93.104.178.103]) by smtp.gmail.com with ESMTPSA id ry1sm14461176wjb.24.2015.09.19.08.23.10 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 19 Sep 2015 08:23:11 -0700 (PDT) User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: <650f78b0-289e-4880-9c03-8615b25360ec@isocpp.org> X-Original-Sender: miro.knejp@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of miro.knejp@gmail.com designates 2a00:1450:400c:c05::22e as permitted sender) smtp.mailfrom=miro.knejp@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:20505 Archived-At: Am 19.09.2015 um 12:33 schrieb Bengt Gustafsson: > I like the basic idea, but here are some comments: > > - Do we really need to be able to specify the introducer character. > Can't % be fixed (with the usual %% escape possibility). I wouldn't mind if it were fixed to "%". Inerestingly "$" seems to be pretty standard in so many other languages. I wonder if that is a more suitable candidate for indicating to the reader "this is not printf!" > > - Wouldn't it be more logical if this resulted in an expanded pack, > i.e. a number of comma separated parts. The use would then be: > > std::string goods = "cars"; > int count = 43; > format(std::cout, F"The number of %goods is %count"); > > which calls a: > > template void format(ostream&, Ps&&...); I wonder which is less work for the compiler (regarding compile times) and, more importantly, the library writer: Having a function object with overloaded operator() for all the types it can handle or writing a variadic template that then has to delegate to actual functions doing the work. The latter can of course use the former, but I wonder which is more tedious to implement. Plus, if you want to do string building efficiently you probably want to use some form of shared state between formatting functions for scratch buffers and O(n) allocations instead of O(n*n). > > Arbitrarily reusing << is a little bit to much of a hack for my taste. > Expanding as a pack to be picked up by a variadic template seems more > like modern C++. The upcoming ... << ... type pack expansions > of C++17 would make the implementation of format a breeze. > > Even with a << expansion I would prefer not to introduce an prefix one > at the left, it seems more logical to write it out explicitly. > > - Translation is an important issue. > > There are utilities which scan the source code to find typically > _("string") literals which get translated. This does not seem to play > well with > this suggestion. Translation is probably the most important reason for > placing the inserts after the string literal in printf and similar, > and this makes inline systems like shifting out on cout > much harder to translate, and this suggested system even worse, as the > parts of the literal can't be "addressed" at runtime so there is no > chance of replacing the string with a translation. String interpolation and translation are two completely different beasts. I see no point mixing them in this proposal as the sentence structure (and language) is fixed at compile time, which is such a poor solution I wouldn't even mention the words translation, localization or i18n *anywhere* in the proposal so people don't get stupid ideas. If you want to do actual localization you need a runtime system that can shuffle the sentence structure. > > Translation is also a main driver behind prefering named inserts, as > different languages tend to want to reorder inserted words to get a > grammatically correct sentence. > > This said there are of course uses when translation is not an issue, > but I'm a bit worried that making untranslatable strings so much > easier to use than translatable strings will make American programmers > (who are as lazy as all programmers and create many of the most used > softwares) conveniently forget about the needs for translation. > > Of course it is still possible to make a preprocessor which actually > mangles the source code inserting the foreign string, but we want to > move away from those ideas towards being able to change language at > runtime. String interpolation doesn't make printf-style formatting obsolete. They do have intersecting use cases, but there is also things you can do with only one or the other. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. .