#![allow(incomplete_features)]
#![feature(generic_const_exprs)]
trait Config {
const N: usize;
}
struct State<C: Config> where [(); C::N]: {
buf: [u8; C::N],
config: C,
}
In current nightly write code like this, then any functions or impls that involve State<C> need to add where [(); C::N]: , and while I know it's necessary, it's verbose and ugly.
Following the unstable-book entry
generic_const_exprs - The Rust Unstable Book
to the tracking issue
further to the design document linked there
Const well-formedness and const equality - HackMD
gives some answer (at the end of the page):
We currently use
where [(); expr]:as a way to add additional const wf bounds. Once we have started experimenting with this it is probably worth it to add a more intuitive way to add const wf bounds.A possible syntax is
where (expr),. This is not intended to be part of the initial unstable implementation however.
So it sounds like, (unsurprisingly IMO,) where [(); expr]: is more of a temporary hack and not the intended solution.
Now your question is not 100% clear to me as to whether you're asking for the syntax to become less verbose (answer to that is "yes", as explained above), or for those bounds to become unnecessary in certain/some/many/all(?) cases alltogether. If it's the latter, then the answer might be that there's not much of a plan to reduce the number of such constrains needed in where clauses, though I don't have anything to quote for that off the top of my head, and its been some time since I've last skimmed the discussion on the Github issue(s) / PR(s) / etc.
There's a reason you had to say
Nonetheless, when this feature implementation becomes complete, could this bound possibly be removed? As opposed to just adding syntax sugar like where (expr).
On a first look, the bound itself doesn't seem to add much information that couldn't be inferred from the rest of the program.
The main argument against this is that in general rust prefers not to use internal details to infer API details. But that’s not entirely true, there are things like auto-traits leaking through RPIT or variance leaking through generic args. I seem to recall some discussion a while ago on whether these bounds are actually useful, but I don’t remember where that was.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.