Duration.toTimeVal ? (following deprecation from 2.066)

[Jonathan M Davis via Digitalmars-d]

On Monday, 11 August 2014 at 06:01:36 UTC, Timothee Cour via 
Digitalmars-d wrote:
> Thanks; shouldn't this be a function ?
> we have SysTime.toTimeVal, why not Duration.toTimeVal?

It was quite a while ago that SysTime was created, so I don't 
know exactly what my thinking was at the time, but I expect that 
I added it because some code would need it, and it wasn't 
necessarily terribly obvious how to create a timeval from a 
SysTime. With Duration, it's quite easy - especially with split - 
so it doesn't add anywhere near as much value there. Also, I 
would expect very little D code to ever need timeval. The only 
reason to use it would be to interact with C code, and the main C 
functions that would need it are wrapped by druntime and/or 
Phobos, making it unnecessary in most code to ever use timeval. 
Obviously, there are cases where it's needed (as evidenced by the 
fact that your code is using it), but the need is likely to be 
rare. So, we're talking about adding a function that saves one 
line of code for something that's easy to do and infrequently 
needed.

timeval tv;
timeout.split!("seconds", "usecs")(tv.tv_sec, tv.tv_usec);

vs

timeval tv = timeout.toTimeVal();

I don't know. I'm not completely against adding it, but it 
doesn't add a lot of value IMHO. It's also very bizarre to use a 
timeval for both a duration and a timestamp, but I guess that 
that's C for you. The main argument I see for adding it is to 
match SysTime.

- Jonathan M Davis