www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Convert TickDuration to Duration?

reply David Nadlinger <see klickverbot.at> writes:
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
Jun 08 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 08 2011
parent reply David Nadlinger <see klickverbot.at> writes:
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
Jun 08 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 08 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jun 09 2011
parent reply simendsjo <simen.endsjo pandavre.com> writes:
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?
Jun 09 2011
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 09 2011
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
Jun 09 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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?
Jun 09 2011
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jun 09 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 09 Jun 2011 14:24:55 -0400, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 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.


The problem with cast (and we've gone over this before ad nauseum) is that  
you can't specify to the compiler what type of cast you are expecting to  
run.  I could think I'm going to invoke opCast, but instead do away with  
some sort of const, or reinterpret the bits as something else.

But I agree, there should be a standard way to hook std.conv.to.  I like  
Andrej's idea of having std.conv.to use a member function named to (or  
opTo?) if possible.

That means, all you need to define in your struct/class is:

T to(T)() if (is(T == Duration)) {...}

then std.conv.to just does x.to!Duration() if it compiles.

It's sort of like std.range.put, which calls put if it exists as a member  
function of an output range, or tries other things if that doesn't work.

-Steve
Jun 09 2011