This is quite annoying:

void main(){
    import std.datetime;
    StopWatch sw;
    import std.stdio;
    writeln(sw.peek().to!("seconds",double));
}

This gives the deprecation warning:
Deprecation: struct std.datetime.StopWatch is deprecated - Use std.datetime.stopwatch.StopWatch.

Then, if I do that:

void main(){
    import std.datetime.stopwatch: StopWatch;
    StopWatch sw;
    import std.stdio;
    writeln(sw.peek().to!("seconds",double));
}

Error: no property 'to' for type 'Duration'

This is among the most basic use cases for StopWatch. For example, if I want to quickly plot some timing data, I'll invariably want to convert times to floating point values of the correct units.

The reason given for this situation is:
https://issues.dlang.org/show_bug.cgi?id=11353

(Jonathan M Davis from comment #4)
> TickDuration will soon be deprecated, and none of the other time stuff
> supports floating point. Anyone who wants that functionality can calculate
> the floating point values from the integral values that the types do
> provide. It's not something that most code should be doing, but the API
> makes it possible for those who care.


"Not something that most code should be doing"? I have never used StopWatch and then /not/ wanted to do something like to!("seconds",double)!

There seems to be no good reason to break my code beyond requiring a different import here. What are the perceived shortcomings of the to!("seconds", double) interface?

On Saturday, November 18, 2017 15:03:05 Timon Gehr via Digitalmars-d wrote:
> This is quite annoying:
>
> void main(){
>      import std.datetime;
>      StopWatch sw;
>      import std.stdio;
>      writeln(sw.peek().to!("seconds",double));
> }
>
> This gives the deprecation warning:
> Deprecation: struct std.datetime.StopWatch is deprecated - Use
> std.datetime.stopwatch.StopWatch.
>
> Then, if I do that:
>
> void main(){
>      import std.datetime.stopwatch: StopWatch;
>      StopWatch sw;
>      import std.stdio;
>      writeln(sw.peek().to!("seconds",double));
> }
>
> Error: no property 'to' for type 'Duration'
>
> This is among the most basic use cases for StopWatch. For example, if I want to quickly plot some timing data, I'll invariably want to convert times to floating point values of the correct units.
>
> The reason given for this situation is: https://issues.dlang.org/show_bug.cgi?id=11353
>
> (Jonathan M Davis from comment #4)
>
>  > TickDuration will soon be deprecated, and none of the other time stuff
>  > supports floating point. Anyone who wants that functionality can
>
> calculate
>
>  > the floating point values from the integral values that the types do
>  > provide. It's not something that most code should be doing, but the API
>  > makes it possible for those who care.
>
> "Not something that most code should be doing"? I have never used StopWatch and then /not/ wanted to do something like to!("seconds",double)!
>
> There seems to be no good reason to break my code beyond requiring a different import here. What are the perceived shortcomings of the to!("seconds", double) interface?

core.time and std.datetime avoid floating point math, because using it introduces errors into the calculations. It does make some sense to generate a floating point value if all you're looking to do is print it out at the end, but using floating point values in the calculations is a source of bugs - e.g. converting between clock frequencies using floating point values would be particularly bad, much as it's the obvious first implementation; core.time.convClockFreq does it all with integral math and avoids the problem and even manages to support a higher range of values in the process than it would if it were implemented with double or real.

As such, I've avoided floating point values like the plague in the time stuff. The only reason that TickDuration does it at all is because it was written by someone else, and it has various design flaws that mean that it really should never have been in core.time in the first place (most notably that it conflates a point in time of the monotonic clock a a duration of the monotonic clock, making it really easy to screw up when using it). So, we've slowly been moving towards getting rid of it in favor of using MonoTime and Duration.

Printing out a floating point value for something like the number of seconds can make sense, but using floating point to do math with time really doesn't. And it's trivial enough to do the math yourself to get the number of seconds (or milliseconds or minutes or whatever) as a floating point value if you really want that that I'd much rather not add it to core.time, because that would just be encouraging folks to start using floating point values for something other than simply printing out the value, which will lead to buggy code which could have easily been avoided just by sticking to integral math.

Folks have asked for the ability to create Durations from floating point values too, and I rejected that for the same reason - using floating point values with time is just begging for bugs, and Walter backed me up on that one.

- Jonathan M Davis

On Saturday, 18 November 2017 at 16:17:00 UTC, Jonathan M Davis wrote:
> On Saturday, November 18, 2017 15:03:05 Timon Gehr via Digitalmars-d wrote:
>> [...]
>
> core.time and std.datetime avoid floating point math, because using it introduces errors into the calculations. It does make some sense to generate a floating point value if all you're looking to do is print it out at the end, but using floating point values in the calculations is a source of bugs - e.g. converting between clock frequencies using floating point values would be particularly bad, much as it's the obvious first implementation; core.time.convClockFreq does it all with integral math and avoids the problem and even manages to support a higher range of values in the process than it would if it were implemented with double or real.
>
> [...]

If you ask me, then time durations doesn't make sense as anything else other than signed integers.

I can see that you can do something like "0.5" for half a second, but really you shouldn't be doing the duration in seconds then, but rather in milliseconds and pass 500 for half a second.

So please, I hope it never gets added.

That's just my two cents.

Especially seeing how flawed floating points are.

On Saturday, 18 November 2017 at 16:17:00 UTC, Jonathan M Davis wrote:
> On Saturday, November 18, 2017 15:03:05 Timon Gehr via Digitalmars-d wrote:
>
> [snip]
>
> Printing out a floating point value for something like the number of seconds can make sense, but using floating point to do math with time really doesn't. And it's trivial enough to do the math yourself to get the number of seconds (or milliseconds or minutes or whatever) as a floating point value if you really want that that I'd much rather not add it to core.time, because that would just be encouraging folks to start using floating point values for something other than simply printing out the value, which will lead to buggy code which could have easily been avoided just by sticking to integral math.
>
When I use timers to measure time durations, whether for program performance or something else, at the end I usually want to convert to units of time appropriate for what is being measured and print it in a format easily consumable by human readers. That typically means some fixed precision floating point format.

I admittedly don't understand the argument that it should be hard to user programs to convert time durations to alternate standard units of measure. But even so, it would seem to make sense for the documentation of std.datetime.stopwatch to provide clear examples of printing a duration in different standard time units. In documentation's current form, it takes quite a bit of digging to figure out how to do this. I'd recommend at least making it clear in the documentation how to do this. Yes, this would also make it easier for users to convert to float, but printing in standard units of measure is a rather basic operation.

On Saturday, 18 November 2017 at 22:46:20 UTC, Jon Degenhardt wrote:

> I admittedly don't understand the argument that it should be hard to user programs to convert time durations to alternate standard units of measure. But even so, it would seem to make sense for the documentation of std.datetime.stopwatch to provide clear examples of printing a duration in different standard time units. In documentation's current form, it takes quite a bit of digging to figure out how to do this. I'd recommend at least making it clear in the documentation how to do this. Yes, this would also make it easier for users to convert to float, but printing in standard units of measure is a rather basic operation.

+1.

I had the same problem with some benchmark intensive project. It took me some time to resolve the deprecations, but I lost more time diging for a way to display times in a human readable form. Internal representations of durations are useless if you cannot display them in a standard unit of measure.

On Sunday, November 19, 2017 15:01:50 Rumbu via Digitalmars-d wrote:
> On Saturday, 18 November 2017 at 22:46:20 UTC, Jon Degenhardt
>
> wrote:
> > I admittedly don't understand the argument that it should be hard to user programs to convert time durations to alternate standard units of measure. But even so, it would seem to make sense for the documentation of std.datetime.stopwatch to provide clear examples of printing a duration in different standard time units. In documentation's current form, it takes quite a bit of digging to figure out how to do this. I'd recommend at least making it clear in the documentation how to do this. Yes, this would also make it easier for users to convert to float, but printing in standard units of measure is a rather basic operation.
>
> +1.
>
> I had the same problem with some benchmark intensive project. It took me some time to resolve the deprecations, but I lost more time diging for a way to display times in a human readable form. Internal representations of durations are useless if you cannot display them in a standard unit of measure.

Was the documentation on Duration not informative enough, or did you have trouble finding it from the documentation for the benchmarking functions, or something else? Simply converting a Duration to a string gives you what I would have thought would have been plenty human readable (though obviously not necessarily what you want in all cases), and it's split and total functions should make it straightforward to put the result in some other format if that's what you want. Was the documentation on those not enough?

- Jonathan M Davis

On Sunday, 19 November 2017 at 16:02:34 UTC, Jonathan M Davis wrote:

> Was the documentation on Duration not informative enough, or did you have trouble finding it from the documentation for the benchmarking functions, or something else? Simply converting a Duration to a string gives you what I would have thought would have been plenty human readable (though obviously not necessarily what you want in all cases), and it's split and total functions should make it straightforward to put the result in some other format if that's what you want. Was the documentation on those not enough?
>
> - Jonathan M Davis

The documentation on Duration doesn't specify any method of converting it to usecs (that's what I need). TickDuration has a usecs member, I really don't care how many ticks are there.

On Sunday, November 19, 2017 16:55:06 Rumbu via Digitalmars-d wrote:
> On Sunday, 19 November 2017 at 16:02:34 UTC, Jonathan M Davis
>
> wrote:
> > Was the documentation on Duration not informative enough, or did you have trouble finding it from the documentation for the benchmarking functions, or something else? Simply converting a Duration to a string gives you what I would have thought would have been plenty human readable (though obviously not necessarily what you want in all cases), and it's split and total functions should make it straightforward to put the result in some other format if that's what you want. Was the documentation on those not enough?
> >
> > - Jonathan M Davis
>
> The documentation on Duration doesn't specify any method of converting it to usecs (that's what I need). TickDuration has a usecs member, I really don't care how many ticks are there.

Duration doesn't have any ticks. As its documentation states, it holds its time internally in hecto-nanoseconds. Its total function can be used to convert the entire Duration to whatever units you want:

https://dlang.org/phobos/core_time.html#.Duration.total

whereas its split function allows you to split it into whatever units you want:

https://dlang.org/phobos/core_time.html#.Duration.split

And simply converting a Duration to a string prints out the units with them split out in a human readable manner. e.g.

    writeln(usecs(502397292));

would print

8 minutes, 22 secs, 397 ms, and 292 μs

https://dlang.org/phobos/core_time.html#.Duration.toString

Subtracting MonoTimes specifically gives a Duration rather than a TickDuration or anything else representing the number of ticks, because you don't normally care about the number of ticks, and its cleaner to have only one duration type. Anyone who wants the number of ticks would have to use MonoTime's ticks property to get at them and then subtract those directly.

So, anything holding the monotonic time now uses MonoTime to hold the times and gives the length of time as a Duration.

- Jonathan M Davis

On Sunday, 19 November 2017 at 17:26:04 UTC, Jonathan M Davis wrote:

> Duration doesn't have any ticks. As its documentation states, it holds its time internally in hecto-nanoseconds. Its total function can be used to convert the entire Duration to whatever units you want:
>
> https://dlang.org/phobos/core_time.html#.Duration.total
>
> whereas its split function allows you to split it into whatever units you want:
>
> https://dlang.org/phobos/core_time.html#.Duration.split
>
> And simply converting a Duration to a string prints out the units with them split out in a human readable manner. e.g.
>
>     writeln(usecs(502397292));
>
> would print
>
> 8 minutes, 22 secs, 397 ms, and 292 μs
>
> https://dlang.org/phobos/core_time.html#.Duration.toString
>
> Subtracting MonoTimes specifically gives a Duration rather than a TickDuration or anything else representing the number of ticks, because you don't normally care about the number of ticks, and its cleaner to have only one duration type. Anyone who wants the number of ticks would have to use MonoTime's ticks property to get at them and then subtract those directly.
>
> So, anything holding the monotonic time now uses MonoTime to hold the times and gives the length of time as a Duration.
>
> - Jonathan M Davis

Thank you Jonathan for the effort of explaini g, better put all this in the docs. Believe me, total is not the first word that comes to my mind when I want to use a conversion. More than that, total is documented on another page. The documentation is lost in details like internal representation (I don't care), mono time (I don't even want to know what is this), operators (I don't see the point of documenting internals) instead of highlighting the main usage.

Now put yourself in the user's shoes. You had something like x.usecs in your code, now you get a deprecation message.

You resolve the deprecation, but the compiler complains:

On Sunday, 19 November 2017 at 17:26:04 UTC, Jonathan M Davis wrote:

> Duration doesn't have any ticks. As its documentation states, it holds its time internally in hecto-nanoseconds. Its total function can be used to convert the entire Duration to whatever units you want:
>
> https://dlang.org/phobos/core_time.html#.Duration.total
>
> whereas its split function allows you to split it into whatever units you want:
>
> https://dlang.org/phobos/core_time.html#.Duration.split
>
> And simply converting a Duration to a string prints out the units with them split out in a human readable manner. e.g.
>
>     writeln(usecs(502397292));
>
> would print
>
> 8 minutes, 22 secs, 397 ms, and 292 μs
>
> https://dlang.org/phobos/core_time.html#.Duration.toString
>
> Subtracting MonoTimes specifically gives a Duration rather than a TickDuration or anything else representing the number of ticks, because you don't normally care about the number of ticks, and its cleaner to have only one duration type. Anyone who wants the number of ticks would have to use MonoTime's ticks property to get at them and then subtract those directly.
>
> So, anything holding the monotonic time now uses MonoTime to hold the times and gives the length of time as a Duration.
>
> - Jonathan M Davis

Thank you Jonathan for the effort of explaini g, better put all this in the docs. Believe me, total is not the first word that comes to my mind when I want to use a conversion. More than that, total is documented on another page. The documentation is lost in details like internal representation (I don't care), mono time (I don't even want to know what is this), operators (I don't see the point of documenting internals) instead of highlighting the main usage.

Now put yourself in the phobos user's shoes.  You had something like sometickdurationresult.usecs in your code, now you get a deprecation message.

I skip the part where I must write now my own benchmarkig functions because someone had the brilliant idea to deprecate them too (why?).

Finally, you resolve the deprecation, but the compiler throws an error like this:

core.time.dur!"usecs".dur (long length) is not callable using argument types (Duration)

Based on the error above, how in the world can I deduce that I must use something like "total"?

Note: I understood what happens, I'm just playing the devil's advocate here :)

On Sunday, November 19, 2017 17:56:37 Rumbu via Digitalmars-d wrote:
> Finally, you resolve the deprecation, but the compiler throws an error like this:
>
> core.time.dur!"usecs".dur (long length) is not callable using
> argument types (Duration)
>
> Based on the error above, how in the world can I deduce that I must use something like "total"?
>
> Note: I understood what happens, I'm just playing the devil's advocate here :)

I would expect you to go read the documentation for Duration if you don't already know how to use Duration.

- Jonathan M Davis