Re: [boost] [chrono/date] date conversion and arithmetic with unvalidated dates

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.

+1

> 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.

+1

>> 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.

Right.

>> 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 :)

Right.

>> 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.

___
Rob

(Sent from my portable computation engine)