_Preface: this is the first time I'm filing an issue on rust-lang/rust. This is a feature request that also seems too small for an RFC. The contrib guidelines are not too clear what to do here, so I hope I'm doing this right._
In https://github.com/rust-lang/rust/issues/57391 there's been conversation about making it easier to construct new time::Durations by using constants:
use std::time;
futures_timer::wait_for(30 * time::SECS).await;
While writing code today I was wondering about easier ways to create Instants. Specifically creating a timestamp that evaluates to _now_ would be useful. As it could be combined with the constants to create an Instant at a particular point in the future.
This is why I would like to propose the addition of a time::now function that would be equivalent to time::Instant::now. The result would be for most programs only the top-level std::time module needs to be imported, and lines dealing with time-related code would be fewer to express the same results.
Thanks!
_Adapted from the time::Instant docs._
use std::{time, thread};
let now = time::now();
thread::sleep(2 * time::SECS);
println!("{}", now.elapsed().as_secs());
use std::time::{Duration, Instant};
use std::thread::sleep;
let now = Instant::now();
sleep(Duration::from_secs(2));
println!("{}", now.elapsed().as_secs());
_edit: I've written a post on this: https://blog.yoshuawuyts.com/std-time/_
Why Instant::now and not SystemTime::now?
I could ask the same question if this was the opposite proposal. Therefore, I don't think this should be done at all. There is no clear default to choose, so requiring disambiguation makes sense.
There are very few free-function constructors in the standard library. Many constants are at the module level simply because associated constants weren't stable in 1.0.
Closing as I think @jethrogb makes a great point and we shouldn't do this.
Most helpful comment
Why
Instant::nowand notSystemTime::now?I could ask the same question if this was the opposite proposal. Therefore, I don't think this should be done at all. There is no clear default to choose, so requiring disambiguation makes sense.