Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Interpret: AllocRange Debug impl, and use it more consistently #98811
Interpret: AllocRange Debug impl, and use it more consistently #98811
Changes from 2 commits
c36572c
d31cbb5
0832d1d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@oli-obk I know you said you didn't like these
alloc_range(...)
calls. OTOH, I tried changing all these functions to offset-size pairs, and it has the usual problems of a function where two arguments have the same type -- call sites become rather ambiguous-looking:This is not an access of size zero.
By using
alloc_range
, at least one has to only learn once what that function does. I originally intended to use this asAllocRange { start: Size::ZERO, size: a_size }
, which is very clear but also very verbose. I wish we could write_ { start: Size::ZERO, size: a_size }
and have rustc infer the type... ;)I am open to other ideas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recently saw a suggestion for
start..+len
, while neat, I find it an extension to the language that definitely does not carry its weight. The additional sigils aren't very obvious or googleable.for slices we at least have
x[start..][..len]
. If indexing could return non-references we could go this route. We could use a method, which is likely not worse than what we have:could become
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw, I think my main complaint is that
read_scalar
and friends take anAllocRange
argument instead of first calling a method to offset/shrink the alloc and then just having no positional arguments toread_scalar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could have a macro,
alloc_range!(start..+len)
? Though not sure if the parser will allow tat.Oh, interesting idea; I had not considered that. But what argument would the restrict-range function take? Another
AllocRange
? Or doesoffset
change the start without changing the end (i.e., it changes both start and size, the way things are currently represented)?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea, this. Could probably use a better name