You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello,
First of, thanks for all the work on const generics. As an embedded user, this is really useful and makes my life significantly more pleasant.
For a big project I'm working on, I've run into an issue where nesting objects using const generics expressions requires repeating bounds in the top-level object that are specified in the lower-level (embedded) object. This makes using this feature difficult, as naming clashes are rife, and it requires implementation details of lower-level objects to be carried-through the hierarchy.
I'm not quite confident I'm explaining this right. To clarify the issue, I've attached a minimal example. UwU embeds OwO. Both have const generics expressions. The compiler gives the following output;
error: unconstrained generic constant
--> src/uwu.rs:12:11
|
12 | woof: OwO<N>,
| ^^^^^^
|
= help: try adding a `where` bound using this expression: `where [(); Q + OWO_CONST - 1]:`
note: required by a bound in `OwO`
--> src/owo.rs:5:10
|
3 | pub struct OwO<const Q: usize>
| --- required by a bound in this
4 | where
5 | [(); Q + OWO_CONST - 1]: Sized,
| ^^^^^^^^^^^^^^^^^ required by this bound in `OwO`
As I understand it, UwU should not need additional bounds due to those imposed in OwO. But, I could definitely be wrong. In any case, all insights are greatly appreciated.
this is related to #41 and we're not yet sure whether we should require these bounds.
If these bounds are required, your issue seems unavoidable though. The bound of OwO is evaluatable(N + 3) while your only other bound is evaluatable(N + U). Without adding the N + 3 bound, UwU<usize::MAX, 0> would have a field which isn't well formed.
What will help determine whether the bounds should be required? As a user, copy-pasting bounds everywhere feels really bad because its verbose and its hard to understand why the compiler needs that.
Thank you for the feed-back. What surprised me most is that internal concerns of one object (how a memory size is computed from const generic parameters) must be propagated upward, thus breaking the "locality of concerns". I'm curious to see how all of this will evolve over time.
Hello,
First of, thanks for all the work on const generics. As an embedded user, this is really useful and makes my life significantly more pleasant.
For a big project I'm working on, I've run into an issue where nesting objects using const generics expressions requires repeating bounds in the top-level object that are specified in the lower-level (embedded) object. This makes using this feature difficult, as naming clashes are rife, and it requires implementation details of lower-level objects to be carried-through the hierarchy.
I'm not quite confident I'm explaining this right. To clarify the issue, I've attached a minimal example. UwU embeds OwO. Both have const generics expressions. The compiler gives the following output;
As I understand it, UwU should not need additional bounds due to those imposed in OwO. But, I could definitely be wrong. In any case, all insights are greatly appreciated.
const_generic_locality_issue.zip
The text was updated successfully, but these errors were encountered: