Re: [boost] [chrono/date] Unit specifiers arithmetic

Subject: Re: [boost] [chrono/date] Unit specifiers arithmetic
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-05-06 21:00:14

On May 6, 2013, at 10:10 AM, Howard Hinnant <howard.hinnant_at_[hidden]> wrote:

> On May 6, 2013, at 9:55 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
> 
>> Le 06/05/13 15:34, Howard Hinnant a écrit :
>>>> 
>>> This is an example of where flexible ordering and implicit last unit starts to shine.  Examples from my 2011 paper:
>>> 
>>>        start = mon <= jan4/(d.year()-1);
>>> 
>>>        date next_start = mon <= jan4/(start.year()+1);
>>> 
>>> Or translated to your example and syntax:
>>> 
>>>    date d(d, m, y+1);  // works because last unit can be int
> 
>> Last unit or any unit but only one?
> 
> Any two explicit units should disambiguate.  We could even take it more lax than that and still avoid ambiguity if desired.

+1

> A warning though:  We want to make the checked syntax more attractive than the unchecked syntax, else all dates will be unnecessarily unchecked in practice.

Separate types can handle the checked/unchecked difference, and both can be equally easy to use.

>>> If we start adding arithmetic to the unit specifier day, it becomes indistinguishable from a duration.  Now it is possible that we could use durations as unit specifiers.
>> -1
> 
> Agreed.

I agree, so long as the unit types convert to int, thereby allowing arithmetic operations. (I think that is implied above, but I wanted to be certain.)

___
Rob

(Sent from my portable computation engine)