Rust: Tracking issue for duration_float

[newpavlov]

Rust PRs: #52813, #59102

This feature adds the following float related methods to Duration:

• as_secs_f64(&self) -> f64
• as_secs_f32(&self) -> f32
• from_secs_f64(secs: f64) -> Duration
• from_secs_f32(secs: f32) -> Duration
• mul_f64(self, rhs: f64) -> Duration
• mul_f32(self, rhs: f32) -> Duration
• div_f64(self, rhs: f64) -> Duration
• div_f32(self, rhs: f64) -> Duration

div_duration methods are tracked in #63139.

[m-ou-se]

What needs to happen before this can be stabilized?

[icefoxen]

f64 vs f32

The only sane options are "have versions for both", or "f64 because it's more general and people can always downcast." You can't fit a billion nanoseconds into the 24 bit significand of a f32.

Also, yes, what needs to happen for this to stabilize?

[newpavlov]

I guess we probably should rename methods to as_f64_secs, from_f64_secs and div_duration_f64, so we will have an option to add analogous f32 methods.

[smokytheangel0]

What can I do to help?

[aloucks]

I guess we probably should rename methods to as_f64_secs, from_f64_secs and div_duration_f64, so we will have an option to add analogous f32 methods.

as_secs_f64 and from_secs_f64 would be more consistent.

[ghedo]

What's left to do to stabilize this feature? Any ETA?

[icefoxen]

It looks like this is finished and can be marked as stabilized, and so incorporated into the next stable release. Is there anything I can do to help with that?

[tyranron]

Is there any discussion or reasoning of why such duplicative interface was chosen?

It seems that a generic interface like from_secs<T>(secs: T) -> Duration will feel more natural/idiomatic for such generics-adopted language like Rust is.

I've found only this mention:

With num_traits::Float we could've reduced number of methods by factor of two, but unfortunately it's not part of std.

But one can argue that in this situation another addhoc inner trait can be introduced in std.

Would you be so kind to explain the reasoning of current stabilized interface?

[faern]

Yeah, having standard library traits for floats and ints implemented by all corresponding types would be good for many places. But this is probably not the place to discuss that in particular.

I also feel this API is very duplicating. My interpretation is that the reasoning behind it is that there is some loss of precision involved with using floats, and people want that to stand out so it does not go unnoticed. See this message and the messages leading up to it: https://github.com/rust-lang/rust/pull/62756#issuecomment-518695524

If there were a Float trait then the two extra methods for each operation could at least be joined to one. For example from_secs_float(secs: impl Float) -> Duration, and the duplication could be cut in half.

EDIT: Probably better to have a specified generic, so callers can explicitly state the resolution: from_secs_float<F: Float>(secs: F) -> Duration. Duration::from_secs_float::<f64>(variable)

EDIT2: This can be done with current standard library like from_secs_float<F: Into<f64>>(secs: F). But it would then also allow passing integers. And it would require the implementation to cast to f64 before actually creating the Duration

[tyranron]

@faern why not something like from_secs<T: DurationFromSecs>(secs: T) -> Duration, where DurationFromSecs can be the inner or public sealed trait (or even not sealed at all, giving users the ability to use custom types) and contains the actual type-specific conversion code (not only floats), while the Duration type API remains simple, ergonomic, yet powerful.

Yeah, having standard library traits for floats and ints implemented by all corresponding types would be good for many places. But this is probably not the place to discuss that in particular.

Would you be so kind to point me to right places where this topic can be raised, discussed and won't remain unnoticed?

[shadiakiki1986]

For future-comers, upgrading to rustc>=1.38 fixes this