220 13432 <1513661.ddTvL7EuaU@tjmaciei-mobl4> article Path: news.gmane.org!not-for-mail From: Thiago Macieira Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: atof(string_view) and others Date: Wed, 01 Oct 2014 08:28:14 -0700 Lines: 102 Approved: news@gmane.org Message-ID: <1513661.ddTvL7EuaU@tjmaciei-mobl4> References: <1816794.VX31jzXomr@tjmaciei-mobl4> <505c0a82-2bbb-44a2-af20-a51f929dfe90@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1412177416 28050 80.91.229.3 (1 Oct 2014 15:30:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Oct 2014 15:30:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCB4TK757YBRBAN4WCQQKGQEJB75V5Y@isocpp.org Wed Oct 01 17:30:11 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f69.google.com ([74.125.82.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XZLr0-0002Hu-Qk for gclcip-std-proposals@m.gmane.org; Wed, 01 Oct 2014 17:30:10 +0200 Original-Received: by mail-wg0-f69.google.com with SMTP id b13sf789604wgh.4 for ; Wed, 01 Oct 2014 08:30:10 -0700 (PDT) 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:message-id:user-agent :in-reply-to:references:mime-version:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=4Ec4mIpS3j53kQwTh0MOfXXUSmuU2IRnzP2ApisCJrU=; b=BdxqWWFKx8oeGFw3vgCG7YvwNTGTVd/tp5hqttrw1x+qFYGJpk/6nml6LU+Uunb4zX vLN6Ix80a/GcCq65D9lMsPJbjp+Q9TYxWtiwbvnQJ3STbSjI8E5vAtYZuEjNS3a/+aTi 9i0k0fkQpwRmtX3vrgXKLS8dbcq8MJkn5/Dd1Y56ZP5QPmYZBW9cSq1tb3oAeBaPZdg/ agjwmLIavORCQJI9NtY1xSKOcDyikLvba0s/tXEi5l6khZn/sQfRJQLnTTZBEYUKOWP2 y3FHCztMdgTRwW6tFXxRpp8m3c+Lcd+XN997Vloa/Sb4xWQHO3XJnOmh4Kmgd6uGtq/c kkew== X-Gm-Message-State: ALoCoQn+is9XL0ITVAE+DDLr8LPxuM+/NVZe6s1eGfLvbqq/obTmXkaty4rNXXWYT9KujwiIYXA1 X-Received: by 10.112.157.193 with SMTP id wo1mr433036lbb.19.1412177410385; Wed, 01 Oct 2014 08:30:10 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.152.8.199 with SMTP id t7ls193491laa.3.gmail; Wed, 01 Oct 2014 08:30:08 -0700 (PDT) X-Received: by 10.152.3.130 with SMTP id c2mr56839349lac.72.1412177408703; Wed, 01 Oct 2014 08:30:08 -0700 (PDT) Original-Received: from gondolin.macieira.info (gondolin.macieira.info. [2a01:4f8:d13:f81:21c:14ff:fe01:12a3]) by mx.google.com with ESMTP id pi7si2341781lbb.15.2014.10.01.08.30.08 for ; Wed, 01 Oct 2014 08:30:08 -0700 (PDT) Received-SPF: pass (google.com: domain of thiago@macieira.org designates 2a01:4f8:d13:f81:21c:14ff:fe01:12a3 as permitted sender) client-ip=2a01:4f8:d13:f81:21c:14ff:fe01:12a3; Original-Received: from tjmaciei-mobl4.localnet (unknown [134.134.139.76]) by gondolin.macieira.info (Postfix) with ESMTPSA id 7736F11BB0E for ; Wed, 1 Oct 2014 08:30:07 -0700 (PDT) User-Agent: KMail/4.14 (Linux/3.11.10-21-desktop; KDE/4.14.0; x86_64; ; ) In-Reply-To: <505c0a82-2bbb-44a2-af20-a51f929dfe90@isocpp.org> X-Original-Sender: thiago@macieira.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of thiago@macieira.org designates 2a01:4f8:d13:f81:21c:14ff:fe01:12a3 as permitted sender) smtp.mail=thiago@macieira.org Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:13432 Archived-At: On Wednesday 01 October 2014 06:22:08 Matthew Fioravante wrote: > > Why not? I don't see the problem with errno (which is actually > > thread-specific, > > not global). > > The alternative to errno is to use std::error_code and return it somehow > either via an out parameter, return value (using out param for the int), or > packaged as part of something like optional / expected / pair / tuple. Does this std::error_code exist already? If it doesn't exist, please don't create it. Everyone and their mom already knows about errno codes and there are entire operating systems based around them. Inventing a new error list sounds counter-productive. Though I think that having a class enum so we can properly separate errors from other uses of integers would be nice. Just as long as the error codes remain 1:1 with errno. > error_code string_to(int& i, string_view& tail, string_view s); > int string_to(error_code& ec, string_view& tail, string_view s); > expected string_to(string_view& tail, string_view s); > > bool string_to(int& i, string_view& tail, string_view s); //sets errno on > failure > int string_to(string_view& tail, string_view s); //sets errno on failure > optional string_to(string_view& tail, string_view s); //sets errno on > failure The tail should be optional. Therefore, it can't be a reference. All those options are out in my book. > > If something threw an exception, whether it was by consumption of the > > disengaged optional or something else, the number conversion is long > > forgotten. How useful is the "number out of range" information three > > frames up > > the stack? > > If my program crashes due to an uncaught exception, "Number of out range" > is a lot more useful to me than "disengaged optional". That assumes that you did not attempt to correct the error. That is, your code has a bug: either you did not validate your input prior to the parsing or you failed to handle the parser errors. I was thinking of normal error conditions, when you did catch the possible errors and report them properly. If the input is allowed to fail parsing to integral value, then you need to report that in the right way to your caller. > The ERANGE may not be as useful three frames up in catch blocks, but a > parsing API which uses exceptions should throw something related to > parsing, not something generic. If we're returning something like optional > which can throw, then we are already introducing exceptions into the entire > API as a whole and at that point we must spend some effort to provide a > quality throwing interface. The return type optional is part of the API. > It's behavior must be considered as an essential part of the whole package. Agreed, but see what I wrote above: if your code can reasonably be expected to fail the parsing, you should check whether it succeeded before proceeding further. If you find out it failed parsing, then you throw your appropriate exception. Don't depend on to_integral doing your job for you. The exceptions it throws and the conditions it finds may not match your API's requirements. > > > Why impose the boilerplate of throwing onto the user? > > > > Simple: so that people who don't use exceptions can still use this > > function. > > > > Despite the direction the standard committee wants to go in, practice is > > that > > there are large and well-known C++ projects that don't use exceptions (see > > the > > Google coding guidelines, applying to Chrome/Chromium, Blink, V8, the > > Mozilla > > coding guidelines, Qt, etc.). > > > > You can easily turn code that uses errno into one that throws in case of > > failure, but you can't compile code reporting errors via exceptions with > > -fno- > > exceptions and still report the errors. > > This is the beauty of optional and expected. It makes exception handling > optional. I'm aware of many projects who decide not to use exception > handling for different reasons. I have a few of my own. I was not aware of expected. If it solves both problems, then let's use it. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 -- --- 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/. .