-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
improve newtype_index! macro #50337
Copy link
Copy link
Closed
Labels
C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
We have this handy macro
newtype_index!that creates a, well, newtype'd index:However, I think it could be improved in four ways:
First, the syntax should change to include the keyword
structandpub. This would help with people trying to find the definition of the type. I'd probably switch to{}form at the same time, but that's not necessary:Second, doing this would also allow us to support arbitrary visibilities. For example, I'd like to make
crate struct RegionAtLocationIndex:Third, we should change to incorporate
NonZero. That is, the original example would currently expands to something like:but I want it to expand to:
Of course,
0is a valid index, so the various initialization and accessor routines would have to add or subtract one as appropriate.Using
NonZerowould mean thatOption<T>would be represented still as a single u32.Finally, fourth, as a convenience, it would be nice to define inherent (non-trait) methods, so that using these types did not require importing the
Idxtrait:cc @Nashenas88 @spastorino @sgrif