While some constant in the modules for the float types are being moved to the float primitive, the ones under the const module have to my knowledge not got any plans to move them? Why is this?
I think you're looking for discussion related to:
opened 07:46PM - 23 Jan 20 UTC
B-RFC-approved
T-libs-api
C-tracking-issue
Libs-Tracked
This is a tracking issue for [the RFC 2700](https://github.com/rust-lang/rfcs/bl… ob/master/text/2700-associated-constants-on-ints.md) (rust-lang/rfcs#2700): "Deprecate stdlib modules dedicated to numeric constants and move those constants to associated consts".
**Steps:**
- [x] Add new constants (see #68325)
- [x] Stabilize new constants ([see instructions on rustc-guide][stabilization-guide])
- [x] Update test suite to use new constants (#78380)
- [x] Fix error messages using old symbols (#78382)
- [x] Support for indeterminate deprecation dates (#78381)
- [x] Deprecate-in-future the old items
- [ ] Fully deprecate the old items
- [x] Adjust documentation ([see instructions on rustc-guide][doc-guide])
[stabilization-guide]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rust-lang.github.io/rustc-guide/stabilization_guide.html#documentation-prs
**Unresolved questions:**
- [x] [Resolved: [Yes](https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696)] Should the old items be deprecated? See the RFC thread as well as ["unresolved questions"](https://github.com/rust-lang/rfcs/blob/master/text/2700-associated-constants-on-ints.md#unresolved-questions):
> How long should we go before issuing a deprecation warning? At the extreme end of the scale we could wait until the next edition of Rust is released, and have the legacy items only issue deprecation warnings when opting in to the new edition; this would limit disruption only to people opting in to a new edition (and, being merely an trivially-addressed deprecation, would constitute far less of a disruption than any ordinary edition-related change; any impact of the deprecation would be mere noise in light of the broader edition-related impacts). However long it takes, it is the opinion of the author that deprecation should happen eventually, as we should not give the impression that it is the ideal state of things that there should exist three ways of finding the maximum value of an integer type; we expect experienced users to intuitively reach for the new way proposed in this RFC as the "natural" way these constants ought to be implemented, but for the sake of new users it would be a pedagogical wart to allow all three to exist without explicitly calling out the preferred one.
- [x] [Resolved: [No](https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696)] Should constants from `std::{f32, f64}::consts` also be made associated consts? From [the alternative question of the RFC](https://github.com/rust-lang/rfcs/blob/master/text/2700-associated-constants-on-ints.md#alternatives):
> Unlike the twelve integral modules, the two floating-point modules would not themselves be entirely deprecated by the changes proposed here. This is because the `std::f32` and `std::f64` modules each contain a `consts` submodule, in which reside constants of a more mathematical bent (the sort of things other languages might put in a `std::math` module).
>
> It is the author's opinion that special treatment for such "math-oriented constants" (as opposed to the "machine-oriented constants" addressed by this RFC) is not particularly precedented; e.g. this separation is not consistent with the existing set of associated functions implemented on `f32` and `f64`, which consist of a mix of both functions concerned with mathematical operations (e.g. `f32::atanh`) and functions concerned with machine representation (e.g. `f32::is_sign_negative`). However, although earlier versions of this RFC proposed deprecating `std::{f32, f64}::consts` (and thereby `std::{f32, f64}` as well), the current version does not do so, as this was met with mild resistance (and, in any case, the greatest gains from this RFC will be its impact on the integral modules).
>
> Ultimately, there is no reason that such a change could not be left to a future RFC if desired. However, one alternative design would be to turn all the constants in `{f32, f64}` into associated consts as well, which would leave no more modules in the standard library that shadow primitive types. A different alternative would be to restrict this RFC only to the integral modules, leaving f32 and f64 for a future RFC, since the integral modules are the most important aspect of this RFC and it would be a shame for them to get bogged down by the unrelated concerns of the floating-point modules.
(Discussions in that issue and in the RFC PR thread, etc.)
I didn't do a full review, but IIUC some feel the more math-related consts deserve separate consideration. (AFAICT deprecating those isn't ruled out but would require its own RFC or APC or whatever.)