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) { … }
---

David

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

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.

David

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.

- Jonathan M Davis

On Wed, 08 Jun 2011 18:02:40 -0400, Jonathan M Davis <jmdavisProg@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?

-Steve

On 09.06.2011 16:33, Steven Schveighoffer wrote:
> On Wed, 08 Jun 2011 18:02:40 -0400, Jonathan M Davis
> <jmdavisProg@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?
>
> -Steve

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

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@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

On Thu, 09 Jun 2011 13:33:28 -0400, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

>> On 09.06.2011 16:33, Steven Schveighoffer wrote:
>> > 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.

What I mean is, whenever you use the blunt instrument 'cast' anything can happen.  This code:

cast(x)y;

can do a lot of damage, depending on what x and y are.  IIRC, you recently said that one should avoid use casting if you can help it :)

It doesn't matter if the underlying cast is safe, the keyword cast means "do whatever I say".  It doesn't mean "do whatever I say but only if it's an opCast operation".  One slight misstep, and the compiler will silently obey instead of giving you an error.  We've been told numerous times "if you want to find all the places where your code bypasses the type system, search for the word cast".

My point is, why can't this function simply be a function (like toDuration()).  You can also define opCast to do the same thing, but I think the ability to avoid typing that dreaded keyword should be available.

-Steve

On 6/9/11, Steven Schveighoffer <schveiguy@yahoo.com> wrote:
> What I mean is, whenever you use the blunt instrument 'cast' anything can happen.  This code:
>
> cast(x)y;
>
> can do a lot of damage, depending on what x and y are.

This was on my mind since I've seen it in std.datetime, and I agree. Isn't it possible for std.conv.to to check if there's a to() function defined in a struct/class and then use that?

On 2011-06-09 10:58, Steven Schveighoffer wrote:
> On Thu, 09 Jun 2011 13:33:28 -0400, Jonathan M Davis <jmdavisProg@gmx.com>
> 
> wrote:
> >> On 09.06.2011 16:33, Steven Schveighoffer wrote:
> >> > 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.
> 
> What I mean is, whenever you use the blunt instrument 'cast' anything can happen. This code:
> 
> cast(x)y;
> 
> can do a lot of damage, depending on what x and y are. IIRC, you recently said that one should avoid use casting if you can help it :)
> 
> It doesn't matter if the underlying cast is safe, the keyword cast means "do whatever I say". It doesn't mean "do whatever I say but only if it's an opCast operation". One slight misstep, and the compiler will silently obey instead of giving you an error. We've been told numerous times "if you want to find all the places where your code bypasses the type system, search for the word cast".
> 
> My point is, why can't this function simply be a function (like toDuration()). You can also define opCast to do the same thing, but I think the ability to avoid typing that dreaded keyword should be available.

I think that it makes good sense to include the opCasts for when they're necessary, but I do agree that it would be ideal not to need them. I'd much prefer to be using to!() than opCast, but I don't know what the proper way to do that is (include overloads for it in core.time and std.datetime?). I didn't include functions like toDuration because it seemed silly to create non- standard, specific functions for that what opCast is intended for. And I don't object to opCast casts in the same way that I object to the built in ones, since it's really just a function call. But I would prefer that to!() be used, since that's appropriately standard and generally safe. I just don't know what the proper way to do that is. It seems overkill to add overloads for every type in Phobos to std.conv, and that doesn't work for types outside of Phobos anyway.

- Jonathan M Davis