Convert TickDuration to Duration?

[Jonathan M Davis]

On 2011-06-09 08:18, simendsjo wrote:
> On 09.06.2011 16:33, Steven Schveighoffer wrote:
> > On Wed, 08 Jun 2011 18:02:40 -0400, Jonathan M Davis
> > 
> > <jmdavisProg at gmx.com> wrote:
> >> On 2011-06-08 14:30, David Nadlinger wrote:
> >>> On 6/8/11 11:14 PM, Jonathan M Davis wrote:
> >>> > On 2011-06-08 13:36, David Nadlinger wrote:
> >>> >> Did I miss a way to convert a TickDuration to a Duration? If there
> >>> >> really is none, is there a reason for this?
> >>> >> 
> >>> >> Having to do an immediate conversion to a hnsecs long feels
> >>> 
> >>> somehow odd:
> >>> >> ---
> >>> >> Duration maxFlushInterval;
> >>> >> if (dur!"hnsecs"(flushTimer.peek.hnsecs)> maxFlushInterval) { … }
> >>> >> ---
> >>> > 
> >>> > Cast it. TickDuration overloaded opCast for Duration.
> >>> > 
> >>> > - Jonathan M Davis
> >>> 
> >>> Oh, of course, totally missed that.
> >> 
> >> I probably should provide an example for it in the documentation
> >> though, since
> >> it's something that you're likely to want to do.
> > 
> > Hm... this involves cast(Duration)x? That seems like a dangerous thing
> > for a common operation, no?

There's nothing dangerous about it. It's an overloaded opCast, not a built-in 
cast. Now, there was some talk of figuring out how to set it up so that you 
could define in your type how to use the to function to convert instead, and 
that would be better (though I have no idea what the situation with that is or 
what's involved in that), but an overloaded opCast is the same as a normal 
function except for its calling syntax, so it's perfectly safe.

> Does this also mean code doing this cannot use @safe? Or is opCast
> excluded by that rule?

I belive that opCast is safe if it's marked with @safe. TickDuration's opCast 
to Duration is not currently @safe. It probably could be. But I need to make a 
pass through core.time and std.datetime one of these days relatively soon and 
mark as much @safe as possible. Right now, very little in them is marked with 
@safe. As long as we lack conditional attributes, a lot of it won't be able to 
be @safe, but it could do a much better job of it than it currently does.

- Jonathan M Davis