220 24785 <87lh647pt4.fsf@gmail.com> article Path: news.gmane.org!not-for-mail From: Moritz Klammler Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Deprecating to_string() for floating point types and introducing a replacement Date: Sun, 28 Feb 2016 17:38:47 +0100 Lines: 77 Approved: news@gmane.org Message-ID: <87lh647pt4.fsf@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1456677536 28568 80.91.229.3 (28 Feb 2016 16:38:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 28 Feb 2016 16:38:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDHI7IWJYALRBGWFZS3AKGQETGIC5AY@isocpp.org Sun Feb 28 17:38:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aa4Mt-0001Pf-PA for gclcip-std-proposals@m.gmane.org; Sun, 28 Feb 2016 17:38:51 +0100 Original-Received: by mail-lb0-f199.google.com with SMTP id ny6sf42988671lbb.0 for ; Sun, 28 Feb 2016 08:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding: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=Xai3DmyCEJ6mTHmivjmnsSzIdUIEHJWAq/9KDuQ2p8U=; b=NQUNPKdRY3U7kV9ZEGHxzCwuNoS8bjMoMNSftUK+XxY5xBVI5a33kMoA3nF4T12CP6 bLKSGK0SiDQtvUjuCUrky1wfIZz9LpfECu/6Q62RO6rBeSAFJomTC1Y0nia2Usx8iyaA kkYEXdrBRLc3DG+AyvdC2BbbmKVMcL8lJHpFrarqjPhTaXsHfaJ+k6otDr2PIxL0ibV9 pqNv7MPBfwgPXVmzH665nWb6bVyl88q09zi/0zUgL09lsIlF71PhxArWW+16kuRp7HLe v9iYLkvIq4YEo3TvnGVc5KsfiRa8Uc0V0QuxPmt1uoWI/9vbEktWB6/5mCpqcPBdd013 N/Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding: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=Xai3DmyCEJ6mTHmivjmnsSzIdUIEHJWAq/9KDuQ2p8U=; b=V3ncVmVtAjQ3arco4DBnEoYZzOcPEtl2Y7Pq7BQbjhNV+fPn48wHWv5rO4Ejm8siqd xNqoWq/EKHkyppBPd6aLxNbuB7VVDX6cmUX8Paz58K+H7RqNGcjCaMwjPI5aHjOKXgIf zno3mqqCJKn/F70/4n+StN34ZYtGZC1RtnRoeugm3sOER7t5bQaB4QIPRLNLJQdoSv3J DvgAdshagETd9eVMn5E5i19DQgrUaCayNj9gg42suvrsaIt+zh/E2DPbfYEJQVzkH6un gINHeYyqOW24Z8ZpvKC0NebHj0TU7pvlL6PvYQ2hvPjiUsX61vaYAmtIQigf9ypmG+um WCI X-Gm-Message-State: AD7BkJKGl038bUHgeDmp3DGRPs+iSISp/M4SONOiULEX+uTiD2wU1rrylSQNckIlo/CLCw== X-Received: by 10.28.128.204 with SMTP id b195mr661760wmd.7.1456677531259; Sun, 28 Feb 2016 08:38:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.139.70 with SMTP id n67ls211672wmd.18.canary; Sun, 28 Feb 2016 08:38:50 -0800 (PST) X-Received: by 10.28.179.84 with SMTP id c81mr7308986wmf.13.1456677530288; Sun, 28 Feb 2016 08:38:50 -0800 (PST) Original-Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com. [2a00:1450:400c:c09::234]) by mx.google.com with ESMTPS id u83si15730939wmb.59.2016.02.28.08.38.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2016 08:38:50 -0800 (PST) Received-SPF: pass (google.com: domain of moritz.klammler@gmail.com designates 2a00:1450:400c:c09::234 as permitted sender) client-ip=2a00:1450:400c:c09::234; Original-Received: by mail-wm0-x234.google.com with SMTP id l68so30642291wml.1 for ; Sun, 28 Feb 2016 08:38:50 -0800 (PST) X-Received: by 10.194.103.72 with SMTP id fu8mr11510970wjb.70.1456677530104; Sun, 28 Feb 2016 08:38:50 -0800 (PST) Original-Received: from moritz-desktop (openvpn-cl-200-76.scc.kit.edu. [141.3.200.76]) by smtp.gmail.com with ESMTPSA id t8sm21740308wjy.41.2016.02.28.08.38.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2016 08:38:48 -0800 (PST) In-Reply-To: u97234@gmail.com's message of "Sun\, 28 Feb 2016 05\:06\:29 -0800 \(PST\) \(2 hours\, 54 minutes\, 54 seconds ago\)" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Original-Sender: moritz.klammler@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of moritz.klammler@gmail.com designates 2a00:1450:400c:c09::234 as permitted sender) smtp.mailfrom=moritz.klammler@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:24785 Archived-At: I have loosely followed the previous discussion and this is a nice write-up. I have a few questions about your proposal. It seems to me that you consider the ability to have lossless round-trips important. I don't think I agree that a lack of this property is an inconsistency with the `to_string` overloads for integers. It's rather inherent to the nature of floating-point. If an application needs value-preserving round-trips (as would be highly desirable for storing numeric values in a text-based database, for example), using "hexfloat" format would be an economic alternative that is almost perfect except that a mere mortal human cannot make sense out of the gibberish. It seems to me that formatting floating-point values for storing in text format and parsing again later without loss and formatting floating-point values for presentation to humans are very distinct use-cases that should not be confused. `std::to_string` should decide which use-case it wants to serve. I opt for the human interface but then the value-preserving property of round-trips is less important an argument. If we choose the other use-case, I'd really expect "hexfloat" as an option. Your current draft doesn't mention "hexfloat" at all. How likely is it that actual software would be broken by changing `std::to_string`'s definition from using `%f` to `%g`? Given all of its problems discussed in your text, it seems to me that the author of any application that uses `std::to_string` today probably didn't think too much about corner cases anyway. Switching from `%f` to `%g` would be a win for both, presenting to humans and storing for later re-use. I think the potential damage would be very limited. Having `to_string` overloaded for all built-in types is useful, especially for writing generic code, so I wouldn't like to deprecate it easily if the undeniable deficits can also be fixed reasonably. > std::string to_string_f(double d, > int precision =3D special_value_requesting_sh= ortest_nonlossy_representation, > char format =3D 'g') noexcept; > > [...] > > If precision or format is not within accepted range, to_string_f() > returns empty string. > > - Handling of out-of-range parameter values should be revised and > defined. The noexcept-property should however be preserved. None of the `std::to_string` overloads today is `noexcept` and given that `std::string`'s constructor isn't, they cannot realistically be. Of course, in practice, SSO will often prevent the need for memory allocation but besides the fact that the standard doesn't mandate it, especially with very long floating-point representations, dynamic memory allocation could easily be required. I also don't think that silently returning an empty string is a good way to communicate invalid inputs. And if I remember correctly, the accepted practice is to only declare functions `noexcept` if they have no preconditions. Many of the conversion functions in =C2=A7 21.5 [string.conversions] are specified to throw `std::invalid_argument` so I don't see why the proposed `std::to_string_f` should deviate from this. Finally, why does it have to be a new function? Couldn't the same benefit be achieved by adding those default arguments to the existing `to_string`? I see that you didn't want to change the `%f` requirement but do like to use `%g` as default for the new function. But as discussed above, I think that this is a risk we might well consider worth taking. --=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/87lh647pt4.fsf%40gmail.com. .