Return Result from Shape methods #6398
Conversation
It's easy to get confused with the width field.
|
IMO, using the last successfully modified width is fine. Actually, that might be the more accurate width in some cases. |
by the way @ding-young thank you for all your excellent work this year! I know you worked closely with @ytmimi and we didn't get a chance to interact much, but i really appreciate all the work you did and I'm glad that you have expressed an interest in remaining engaged with it |
@camsteffen - re: this item, i've not looked at the diff yet but if there's a change to the formatting output (even if it's an improvement) then we'll need to edition gate it behind style edition 2027 e.g. Line 147 in 777e25a |
There should be no change in user-facing behavior, formatting. Just a change to the contents of the error object, which is currently never used IIUC. |
| let nested_shape = shape | ||
| .shrink_left(binder.len() + const_.len() + immovable.len() + coro.len() + mover.len()) | ||
| .and_then(|shape| shape.sub_width(4)) | ||
| .max_width_error(shape.width, span)?; | ||
| .shrink_left( | ||
| binder.len() + const_.len() + immovable.len() + coro.len() + mover.len(), | ||
| span, | ||
| )? | ||
| .sub_width(4, span)?; |
There was a problem hiding this comment.
Could consider defining the offset outside of the call to shrink_left:
let offset = binder.len() + const_.len() + immovable.len() + coro.len() + mover.len();
let nested_shape = shape.shrink_left(offset, span)?.sub_width(4, span)?;| pub(crate) fn block_left(&self, width: usize) -> Option<Shape> { | ||
| self.block_indent(width).sub_width(width) | ||
| pub(crate) fn block_left(&self, n: usize, span: Span) -> Result<Shape, ExceedsMaxWidthError> { | ||
| self.block_indent(n).sub_width(n, span) |
There was a problem hiding this comment.
nit: lets keep the variable named width. I'd like to keep this consistent for all the functions below as well.
There was a problem hiding this comment.
I had done that initially and it tripped me up because .map(|width| Shape { width, ... shadows the argument. I wanted to change it because the field width and the argument width are totally different things. Of course I can work around that though.
There was a problem hiding this comment.
I'd be fine naming it something other than width, but I think it would be nice if it were more descriptive than n. Maybe offset? I'm open to suggestions.
There was a problem hiding this comment.
Offset is good. Or amount, distance, delta.
There was a problem hiding this comment.
Any of those work for me. I'll leave it up to you on which one you think would work best.
| self.width | ||
| .checked_sub(n) | ||
| .map(|width| Shape { width, ..*self }) |
There was a problem hiding this comment.
Would it be better to define sub_width_opt, and really all the *_opt functions in terms of their Result<T, MaxWidthError> versions?
pub(crate) fn sub_width_opt(&self, n: usize) -> Option<Shape> {
self.sub_width(n, rustc_span::DUMMY_SP).ok()
}There was a problem hiding this comment.
I considered that and I opted to avoid using DUMMY_SP. But it's not a strong preference for me.
There was a problem hiding this comment.
Another possibility is to go the other way around with something like sub_width_opt(n).ok_or_else(|| self.max_width_error(span))
There was a problem hiding this comment.
I think you're second idea would be a nice way to avoid using a DUMMY_SP.
Shapemodifier methods now returnResult<Shape, ExeedsMaxWidthError>_optvariants of the methods for when an Option is still needed