-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking Issue for complex generic constants: feature(generic_const_exprs)
#76560
Comments
const_evaluatable_checked
)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The MCP mentions that
are allowed and will be "unified". Isn't that incompatible with impure |
Also, in terms of arithmetic, it might be better to exclude floating-point arithmetic since at least some models propose to make that arithmetic non-deterministic (specifically, the NaN payload may be non-deterministic) -- also see rust-lang/unsafe-code-guidelines#237. |
uh, now that's a challenge I didn't think of 😆 not yet sure how do we expect to deal with |
The interesting case is Note that the non-determinism is very restricted; it only arises in the |
So I was looking through the current design for this feature and noticed that there isn't a clear definition of how const generics should interact with associated consts. I filed #80976 and #80977 for specific errors that show up when associated consts are used in const generics directly, but noticed that we don't actually have any defined syntax for how you would constrain associated consts in bounds, e.g. something like fn mat_mul<L, R>(dest: &mut D, lhs: &L, rhs: &R)
where
D: MatrixMut,
L: Matrix<Scalar = D::Scalar, const ROWS = D::ROWS>,
R: Matrix<Scalar = D::Scalar, const COLS = D::COLS, const ROWS = L::ROWS>
{
// ...
} I figure that this is probably something that needs to be figured out before this feature can be merged, even if the decision is that associated consts simply aren't allowed at all for MVP (which IMHO wouldn't be that great of an idea, but would still resolve the issues I mentioned). |
@clarfonthey This is a feature I'm in mighty need of in my personal project using const generics, I'd love to be able to use associated consts more heavily and do something like this (Cool Things I Want to Do(tm) are highlighted with trait Sample: Copy + Clone + PartialOrd + PartialEq {
const EQUILIBRIUM: Self;
}
trait Frame: Copy + Clone + PartialEq {
type Sample: Sample;
const NUM_CHANNELS: usize;
const EQUILIBRIUM: Self;
// Returns a fixed array of of `Self::Sample`s of size `Self::NUM_CHANNELS`.
fn to_array(self) -> [Self::Sample; { Self::NUM_CHANNELS }]; // !!!!!!!!
}
// All fixed-size arrays of samples are frames.
impl<S, const N: usize> Frame for [S; N]
where
S: Sample,
{
type Sample = S;
const NUM_CHANNELS: usize = N;
const EQUILIBRIUM: Self = [S::EQUILIBRIUM; Self::NUM_CHANNELS]; // !!!!!!!!
// Already an array, just return `self`.
// I would hope [S; N] and [S; Self::NUM_CHANNELS] are realized to be the same type!
fn to_array(self) -> [Self::Sample; { Self::NUM_CHANNELS }] { // !!!!!!!!
self
}
}
// Standalone function to show example of const generic bound restrictions.
fn pair_test<A, B, F>(frame_a: A, frame_b: B, mut test_func: F) -> bool
where
A: Frame,
// Same constant number of channels.
B: Frame<const NUM_CHANNELS = A::NUM_CHANNELS>, // !!!!!!!!
F: FnMut(&A::Sample, &B::Sample) -> bool,
{
todo!("pretend this is a calculation that expects two arrays of the same size")
} Right now however, using trait Sample: Copy + Clone + PartialOrd + PartialEq {
const EQUILIBRIUM: Self;
}
// This trait now has a const generic parameter.
trait Frame<const N: usize>: Copy + Clone + PartialEq {
type Sample: Sample;
const NUM_CHANNELS: usize;
const EQUILIBRIUM: Self;
fn to_array(self) -> [Self::Sample; N];
}
impl<S, const N: usize> Frame<N> for [S; N]
where
S: Sample,
{
type Sample = S;
const NUM_CHANNELS: usize = N;
const EQUILIBRIUM: Self = [S::EQUILIBRIUM; N];
fn to_array(self) -> [Self::Sample; N] {
self
}
}
// Now, I have to include a `const N: usize` bound, even though this new method
// doesn't directly use its value. The value of `N` is only used to ensure that
// the two frames have the same number of channels. This kind of const generic
// pollution is especially bad when returning values parameterized by types that
// have const generics.
fn pair_test<A, B, F, const N: usize>(frame_a: A, frame_b: B, mut test_func: F) -> bool
where
A: Frame<N>,
B: Frame<N>, // Same constant number of channels.
F: FnMut(&A::Sample, &B::Sample) -> bool,
{
todo!("pretend this is a calculation that expects two arrays of the same size")
} |
I would expect that the following deduction would work and so the extra bound on the final create function wouldn't be needed. Is this out of the scope of this RFC ?
code:
(btw replacing the final |
=== stdout === === stderr === warning: the feature `const_generics` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/78246.rs:1:12 | 1 | #![feature(const_generics, const_evaluatable_checked)] | ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <rust-lang/rust#44580> for more information warning: the feature `const_evaluatable_checked` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/78246.rs:1:28 | 1 | #![feature(const_generics, const_evaluatable_checked)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <rust-lang/rust#76560> for more information error[E0308]: mismatched types --> /home/runner/work/glacier/glacier/ices/78246.rs:15:28 | 15 | fn into_bytes(self) -> Self::Array {} | ---------- ^^^^^^^^^^^ expected array `[(); _]`, found `()` | | | implicitly returns `()` as its body has no tail or `return` expression error: aborting due to previous error; 2 warnings emitted For more information about this error, try `rustc --explain E0308`. ==============
=== stdout === === stderr === warning: the feature `const_generics` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/80561.rs:1:12 | 1 | #![feature(const_generics)] | ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <rust-lang/rust#44580> for more information warning: the feature `const_evaluatable_checked` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/80561.rs:2:12 | 2 | #![feature(const_evaluatable_checked)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <rust-lang/rust#76560> for more information warning: 2 warnings emitted ==============
=== stdout === === stderr === warning: the feature `const_generics` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/80561.rs:1:12 | 1 | #![feature(const_generics)] | ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <rust-lang/rust#44580> for more information warning: the feature `const_evaluatable_checked` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/80561.rs:2:12 | 2 | #![feature(const_evaluatable_checked)] | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #76560 <rust-lang/rust#76560> for more information warning: 2 warnings emitted ============== Co-authored-by: rustbot <rustbot@users.noreply.github.com>
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Until generic_const_exprs is stabilized (rust-lang/rust#76560), or an alternative is found, the zorua crate will be nightly only.
Until generic_const_exprs is stabilized (rust-lang/rust#76560), or an alternative is found, the zorua crate will be nightly only.
Remove `try_from_lit` from `from_anon_const` This PR tries to fix rust-lang#116308. TODO: - [ ] write up the reason why `try_from_lit` should be removed from `from_anon_const` - [ ] write up the reason why it is safe to do this - [ ] do a perf run and see if doing this affect performance ui tests changes: - [ ] failed run-pass/check-pass (`const-arg-in-const-arg.rs#full`, `abstract-const-as-cast-4.rs`, `no_dependence.rs`, `issue-94293.rs`) - [ ] symbol mangling affected (`symbol-names/*`) - [ ] different error report (`const-projection-err.rs#gce`, `abstract-const-as-cast-3.rs`, `type_mismatch.rs`) - [x] misc - error report reordering - same error, but different const type reprs This PR is related to two unstable features (`adt_const_params`: rust-lang#95174, `generic_const_exprs`: rust-lang#76560). r? `@BoxyUwU`
This is a tracking issue for complex generic expressions in constants which is still highly experimental.
The feature gate for the issue is
#![feature(generic_const_exprs)]
.On stable all const generic arguments must be either:
Foo<{ bar(1 + 2) }
Foo<{ N }>
This feature allows arbitrary usage of generic parameters in const generic arguments such that
Foo<{ bar(N + 2) }>
is now legal.Initial proposal: rust-lang/compiler-team#340
Design document: HackMD document
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Status
The design questions and implementation challenges are collected in the project-const-generics repository. The implementation is still far from ready but already available for experimentation.
The text was updated successfully, but these errors were encountered: