Make Duration constructors and accessors const fns

[sfackler]

Closes #33029

r? @alexcrichton

[GuillaumeGomez]

Thanks!

r=me

[luqmana]

@bors: r=GuillaumeGomez

[bors]

📌 Commit 379c40f has been approved by GuillaumeGomez

[alexcrichton]

@bors: r-

@GuillaumeGomez this is a change which has ramifications on the stability of these APIs and how we might change them in the future, I'd like to discuss this at a libs triage meeting before we move forward with this just yet.

We currently don't have many conventions for what is or what isn't a const fn in the standard library just yet, and we have many possible candidates for doing so, so I want to just make sure we approach this in a principled fashion rather than "let's make everything const which can be so right now"

[GuillaumeGomez]

@alexcrichton: My bad, I didn't think that the change would be that big. I'll wait for your come back on this.

[steveklabnik]

@luqmana to be clear, @GuillaumeGomez doesn't quite have r+ rights yet. I've been working with him on smaller things, but I'm supposed to approve them before they get put in. (and even that is docs only, not code). He forgot to CC me on this one.

I'm surprised Bors allowed this, actually.

[luqmana]

@steveklabnik Ah whoops, my mistake. Actually, I don't think bors cares what comes after r= as long as the person actually writing the comment is allowed to.

[oli-obk]

These kind of const fns only work in statics, they don't work in array lengths and other true constants (yet). Is there a use case for this? If not, I suggest to delay this until we have a unified MIR-powered const evaluator

[alexcrichton]

The libs team discussed this PR during triage today and the decision was to close for now. Adding a const fn is a serious API commitment that we may not always be able to uphold (e.g. #33072). In the meantime const fn is still unstable, and when stabilized we will likely want to perform a pass over the standard library to audit for functions which are const-compatible at that time.