Skip to content

It is not possible to assign a Duration to a const variable #18166

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
carllerche opened this issue Oct 19, 2014 · 4 comments
Closed

It is not possible to assign a Duration to a const variable #18166

carllerche opened this issue Oct 19, 2014 · 4 comments

Comments

@carllerche
Copy link
Member

The struct fields are currently not pub making it impossible to assign Duration to a const variable.

Given that Duration is essentially timespec, it seems like it might be a good idea to make the struct fields public.

cc @aturon

@ben0x539
Copy link
Contributor

There's a legit timespec in liblibc by the way. I don't think the field sizes are compatible, though.

@Gankra
Copy link
Contributor

Gankra commented Oct 20, 2014

Can this wait for Compile Time Function Evaluation to be implemented properly? It seems like that would be the correct solution to this problem (unless having the fields public is otherwise desirable).

1-more added a commit to 1-more/rust that referenced this issue Nov 3, 2014
This commit changes the internal representation of Duration from

    pub struct Duraion {
        secs: i64,
        nanos: i32
    }

to

    /// An absolute amount of time, independent of time zones
    /// and calendars with tick precision. A single tick
    /// represents 100 nanoseconds.
    pub struct Duration(pub i64)

Closes rust-lang#18166,rust-lang#18416.
@steveklabnik
Copy link
Member

This is still true today.

@steveklabnik
Copy link
Member

Sample program:

use std::time::Duration;

const MINUTE: Duration = Duration::new(60, 0);

fn main() {}

This is basically always going to be true until const fn is stable, since things are now stable, so there's not much we can really do here, so I'm giving this a close.

lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
…Veykril

fix: Fix a bug in span map merge, and add explanations of how span maps are stored

Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.

The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.

Fixes rust-lang#18163.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants