Jonathan M Davis Wrote: > > I would point out though, that as it stands, including std.datetime would > require including my time module as core.time (which has been discussed to > some > extent with Sean, since it was pretty much his idea in the first place that > some > level of integration should occur there) as well as including my unittests > module as something like std.unittests (which was reviewed here on some > level, > and has definitely been improved from its initial version, but hasn't exactly > had > overwhelming support). The unittest functions could be integrated privately > into > std.datetime, but I think that that would be a disservice to the community at > large.
I don't mean to confuse the issue, but since neither of these are necessary attributes of std.datetime, they shouldn't be considered as such. I think it's entirely reasonable for the unittest stuff to be made private and std.unittests to be created later, or for some code movement from Phobos to Druntime to occur later as well. For the uninformed, the latter issue came up because Druntime needs some structured way to represent durations for operations like Thread.sleep(), and the argument was made that Druntime use whatever duration type is in std.datetime rather than having a functionally similar type, possibly with a similar name, etc.
