[D-runtime] druntime commit, revision 410

[Steve Schveighoffer]

That sound exactly like what I wanted, thanks!

BTW, when I said I think std.datetime should use core.time.Duration as its 
duration type, I meant that in terms of where the Duration type was located, not 
which implementation should be used.  I guess I didn't really make that clear.  
Definitely, we should use the most complete implementation.

-Steve



----- Original Message ----
> From: Jonathan M Davis <jmdavisProg at gmx.com>
> 
> 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
> _______________________________________________
> D-runtime mailing  list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>