[D-runtime] druntime commit, revision 410

[Jonathan M Davis]

On Thursday 04 November 2010 12:51:36 Steve Schveighoffer wrote:
> Without looking at it at all, my firm belief is that std.datetime should
> use core.time.Duration as its duration type.  One of the big issues I had
> with Tango before implementing the time types was that you had 3 or 4
> different ways to specify time.
> 
> In all likelyhood you are going to be using std.datetime to do most of your
> code since it provides mechanisms that work with the local clock.  If you
> then have to convert your std.datetime structs to core.time structs in
> order to call core functions, that's going to be a huge turnoff.
> 
> In addition, std.datetime should publicly import core.time so it's seamless
> to the person who wants to work with time structures.
> 
> I know the datetime stuff is not final yet, but Jonathan, can we look at
> what duration type should be moved to core.time?

Looking at core.time, I'd really suggest just moving over std.datetime.Duration 
to core.time along with TickDuration, FracSec, and the dur!() function for 
creating Durations, possibly along with some of the helper functions (which I 
believe are primarily restricted to template constraints). Most of the unit 
tests would have to be made to not use my nice unit test functions, so the unit 
tests would become a bit nastier, and some of the unit tests would probably have 
to be left in std.datetime, since they rely on Clock.currSystemTick() (or it 
could be removed from Clock, though I'd prefer not), but it can be done.

In any case, with some alterations, I think that std.datetime.Duration and the 
other pieces of std.datetime that it relies on can be moved into core.time 
fairly easily. I really think that on the whole, std.datetime.Duration is 
superior to core.time.Duration, so I definitely don't want to replace 
std.datetime's Duration with core.time's Duration.

I can spend some time to create a version which could replace what's currently 
in core.time, and then std.datetime can publicly import core.time as Steve 
suggests.

- Jonathan M Davis