Subject: Re: [boost] [chrono/date] date conversion and arithmetic with unvalidated dates
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-06 21:16:25
On May 6, 2013, at 6:54 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
> Le 06/05/13 22:57, Anurag Kalia a Ã©crit :
>> I am afraid I don't like this separation of dates. The current model as it stands simply says that the dates constructed with "raw" constructor are undefined.
There's no such thing as a "raw" constructor, unless you name a class "raw". These are semantics you have chosen to apply to constructors versus free functions.
Note that "make_date" is practically the same as the constructor for a type named "make_date".
>> Also, dates constructed with validation check are of course valid. Combining
>> the two, we have always valid dates when created. Thus, operations define
>> their behaviour on valid dates only. It doesn't mean operation is always defined for valid dates. As your example suggests, "2013-02-29" + 1 year = "2013-02-29" which doesn't exist! Thus it is possible for valid dates to
>> have no defined answer for that operation. We can either throw an error, or extend our operation to include those dates, say "29 feb" + 1 year maps to "28-feb" now.
> In order to do that you need some kind of validation. This is exactly my concern.
> Should the year arithmetic be as efficient as possible (just increate the year) and let the user to ensure the require clauses of the function)?
> I would say yes, and this should be the behavior for unchecked dates.
> Or should the operation check if the resulting date is a valid one a throw otherwise?
> I would say yes, and this should be the behavior for checked dates.
> Once we have defined both behaviors and assign them to a specific class the user can move from checked to unchecked and vice versa depending on what she wants to do and using always the same syntax.
>> The same can be said in the cases of underflow or overflow.
>> The path we choose for those dates can be argued and debated, but what we are not arguing is the validity of the input dates.
>> But as you rightly ponder over is how to validate an unvalidated date. We can always create a date from the previous date using functions that validate it, say make_date(). To ease it, we can create function:
>> make_date(date unvalidated);
>> make_date() as before uses validation while construction of dates.
> Yes, but the C++type system is not helping us to define the correct behavior.
>> The question though remains whether we can ever check a date for validation. As I said before, it is impossible for serial-based implementation.
> Except if you ensure that because the type valid_date has only checked and valid dates :)
>> So, I am in favour scrapping any such effort and dumping any interaction with an
>> unvalidated date in the undefined behaviour.
> Well this is your right.
...or wrong (since I don't agree :).
> I'm just supporting the Rob idea that maybe we need both with a close interaction if we want a clear design and easy to use/learn interface.
Remember that part of such an interface is to help the user do the right thing.
(Sent from my portable computation engine)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk