220 18072 <555D03F2.4040505@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Parsing Numbers Date: Thu, 21 May 2015 00:00:18 +0200 Lines: 249 Approved: news@gmane.org Message-ID: <555D03F2.4040505@wanadoo.fr> References: <2264844.2f9Wn7Zsb9@tjmaciei-mobl4> <010af437-2f84-4afe-ae09-3e6f6edeb9b8@isocpp.org> <79b0dd51-6723-4ae5-b963-3763d611d8b7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080507040607030000090303" X-Trace: ger.gmane.org 1432159230 3855 80.91.229.3 (20 May 2015 22:00:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 May 2015 22:00:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB5EH6SVAKGQEHXGL5BI@isocpp.org Thu May 21 00:00:21 2015 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 1YvC2H-0004oq-OO for gclcip-std-proposals@m.gmane.org; Thu, 21 May 2015 00:00:21 +0200 Original-Received: by lbbuh7 with SMTP id uh7sf1534759lbb.3 for ; Wed, 20 May 2015 15:00:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=xPtsTGcjKgeXSDvxdWxKK1Y8VQAZRvX7NV+/B9eA1M4=; b=CoYG5nbZ+fOKAcuT4gnzsTHNVZOJtnAMHj4tu0UBrmyMUGEZVM9ZQWF0u7BMMKH7V0 GLdyVk73OZiq4VELYPCXtx4mOFYy/80eg7PPN8dETi8MZojfHcxH1Zqr0ttQiCKD4qMc BAnm/32cqZDs8fhknozcxWgU2W9RPu7TiXxjKZP8BGhkt88XGOpyjFb5IW1jfu6z5ip9 2LxmKIaCs0F+kIxz8gFVrdAET0tpIyfdhdRAUfTF1o+k49ELpkuIDt1S+xHtDjOG0qz9 ON1EakuPcCWEkDXpA+RtwK0CYhqa6SrXBbSrS5Z7qDvxxnEn7g5AlSX7MX6iDa2SwqyR 2urg== X-Gm-Message-State: ALoCoQmH9mxnf3qg1zAdoXj2L8piv0b3T02ckpVnmZdM2izPsdoMURrFqma2wzsTrAmFu/grjssY X-Received: by 10.112.28.111 with SMTP id a15mr28166170lbh.21.1432159221371; Wed, 20 May 2015 15:00:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.101.227 with SMTP id fj3ls1018460wib.46.canary; Wed, 20 May 2015 15:00:19 -0700 (PDT) X-Received: by 10.180.78.65 with SMTP id z1mr122155wiw.14.1432159219913; Wed, 20 May 2015 15:00:19 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126]) by mx.google.com with ESMTPS id gh2si4787306wib.11.2015.05.20.15.00.19 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 May 2015 15:00:19 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.126; Original-Received: from new-host.home ([92.139.141.131]) by mwinf5d60 with ME id WN0K1q0022qJ0z803N0Kfe; Thu, 21 May 2015 00:00:19 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 21 May 2015 00:00:19 +0200 X-ME-IP: 92.139.141.131 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr 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:18072 Archived-At: This is a multi-part message in MIME format. --------------080507040607030000090303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 20/05/15 20:49, Olaf van der Spek a =C3=A9crit : > 2015-05-20 17:43 GMT+02:00 Matthew Woehlke : >> On 2015-05-20 11:27, Matthew Fioravante wrote: >>> Generally, using 0 or any other perfectly valid value to signal failure= is >>> a really bad idea. It only makes sense when your use case is "Parse the >>> value or give me some default if it fails". In that case, 0 may not be = the >>> default value you want so its better to be able to actually specify it. >> Doesn't expected already handle this? > Does expected exist? Do you mean an implementation to play with? Yes=20 (https://github.com/ptal/expected) > And does it have something like test_and_set()? No. What test_and_set would have as parameters and what would be the effect= ? > What would a parse date (Y-M-D) function look like? > > // returning expected or optional > optional parse_date1(string_view is) > { > int year; > int month; > int day; > return true > && test_and_set(year, parse(is, &is)) > && parse_separator(is, &is) > && test_and_set(month, parse(is, &is)) > && parse_separator(is, &is) > && test_and_set(day, parse(is, &is))) > ? { year, month, day } > : {}; > } > > // returning error_code > optional parse_date2(string_view is) > { > int year; > int month; > int day; > return true > && !parse(year, is, &is)) > && !parse_separator(is, &is) > && !parse(month, is, &is)) > && !parse_separator(is, &is) > && !parse(day, is, &is))) > ? { year, month, day } > : {}; > } > > One of these functions looks cleaner to me. Did I do something wrong? > Using a tail as out parameter it should be someting like expected parse_date(string_view is, string_view& out) { return make_date % // fmap ( parse(is, &is) // year >> parse_separator(is, &is) ) * ( parse(is, &is) // month >> parse_separator(is, &is) ) * parse(is, &out) // day ; } or using the functional form with a parameter in-out it could be expected parse_date(string_view& is) { return fmap(make_date, mdo( parse(is), // year parse_separator(is) ), mdo( parse(is), // month parse_separator(is) ), parse(is) // day ); } There other possibilities (e.g. using Parser) as Miro pointed out. Vicente --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --------------080507040607030000090303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 20/05/15 20:49, Olaf van der Spek a =C3=A9crit=C2=A0:
2015-05-20 17:43 GMT+02:00 Matthew Woehlke <=
mw_triad@users.sourceforge.net>:

On 2015-05-20 11:27, Matthew Fioravante wrote:

Generally, using 0 or any other perfectly valid va=
lue to signal failure is
a really bad idea. It only makes sense when your use case is "Parse the
value or give me some default if it fails". In that case, 0 may not be the
default value you want so its better to be able to actually specify it.

Doesn't expected already handle this?

Does expected exist?
Do you mean an implementation to play with? Yes (https://github.com/ptal/expected)
And does it have something like test_and_set()?
No. What test_and_set would have as parameters and what would be the effect?

What would a parse date (Y-M-D) function look like?

// returning expected or optional
optional<Date> parse_date1(string_view is)
{
  int year;
  int month;
  int day;
  return true
    && test_and_set(year, parse<decltype(year)>(is, &is))
    && parse_separator(is, &is)
    && test_and_set(month, parse<decltype(month)>(is, &is=
))
    && parse_separator(is, &is)
    && test_and_set(day, parse<decltype(day)>(is, &is)))
    ? { year, month, day }
    : {};
}

// returning error_code
optional<Date> parse_date2(string_view is)
{
  int year;
  int month;
  int day;
  return true
    && !parse(year, is, &is))
    && !parse_separator(is, &is)
    && !parse(month, is, &is))
    && !parse_separator(is, &is)
    && !parse(day, is, &is)))
    ? { year, month, day }
    : {};
}

One of these functions looks cleaner to me. Did I do something wrong?
Using a tail as out parameter it should be someting like

expected<Date, error_code> parse_date(string_view =
is, string_view& out)
{
  return make_date % // fmap
	( parse<int>(is, &is) 	// year
		>> parse_separator(is, &is) ) *=20
	( parse<int>(is, &is)  	// month
		>> parse_separator(is, &is) ) *
	  parse<int>(is, &out)	// day
	;=20
}
or using the functional form with a parameter in-out it could be
expected<Date> parse_date(string_view& is)
{
  return fmap(make_date,=20
		mdo( parse<int>(is),	// year
		     parse_separator(is) ),=20
		mdo( parse<int>(is),  	// month
		     parse_separator(is) ),
		parse<int>(is)  	// day
	     );
}
There other possibilities (e.g. using Parser) as Miro pointed out.

Vicente

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--------------080507040607030000090303-- .