Skip to content

Replace uses of Result, in which Err variant contains non-error type, with custom enums #93194

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

Closed

Conversation

b-naber
Copy link
Contributor

@b-naber b-naber commented Jan 22, 2022

There are some functions that use Result::Err to return some value that isn't an error. I found these a little confusing, especially in contexts in which we have nested Result types.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jan 22, 2022
@b-naber
Copy link
Contributor Author

b-naber commented Jan 22, 2022

r? @lcnr

@lcnr
Copy link
Contributor

lcnr commented Jan 25, 2022

r=me, but want @oli-obk or @RalfJung to chime in whether the try_read_immediate to read_immediate_or_mplace rename is fine or if returning an mplace is actually represents a failure.

@oli-obk
Copy link
Contributor

oli-obk commented Jan 25, 2022

These APIs were defined with Result somewhat on purpose. The standard library has this situation for other owned functions that attempt something and return the value itself otherwise.

I guess here we mostly use it to return whatever the function name suggests in the Ok and return the other representation of the value as Err. I don't like the verbosity of the new API, but that may just be because I'm used to it. I agree that it's confusing to have to figure out the Ok(Ok(...)) situations. Not sure what the best way forward is.

@RalfJung
Copy link
Member

To simplify reviewing I think it would be better to split up the PR into multiple commits or even multiple PRs, one for each new enum.

Regarding try_read_immediate: what I would give for anonymous sum types... but using a custom enum is probably the right thing here, I was just too lazy to do this. ;) The fact that ImmediateOrMPlace is used in 2 places is a good sign.

However, read_immediate_or_mplace sounds a bit like this might read an mplace, so I am not particularly happy with the new name. Unfortunately I cannot come up with a better one either... any ideas?

}

impl<'tcx, Tag: Provenance> ImmediateOrMPlace<'tcx, Tag> {
pub fn get_mplace(self) -> MPlaceTy<'tcx, Tag> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe unwrap_mplace would be better? At least it indicates that this might panic.

@b-naber
Copy link
Contributor Author

b-naber commented Jan 25, 2022

However, read_immediate_or_mplace sounds a bit like this might read an mplace, so I am not particularly happy with the new name. Unfortunately I cannot come up with a better one either... any ideas?

How about something like try_read_immediate_else_mplace?

@camelid camelid added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 29, 2022
@bors
Copy link
Collaborator

bors commented Feb 23, 2022

☔ The latest upstream changes (presumably #94286) made this pull request unmergeable. Please resolve the merge conflicts.

@lcnr
Copy link
Contributor

lcnr commented Feb 28, 2022

However, read_immediate_or_mplace sounds a bit like this might read an mplace, so I am not particularly happy with the new name. Unfortunately I cannot come up with a better one either... any ideas?

How about something like try_read_immediate_else_mplace?

i think that's good enough, though at this point using Result seems sensible again

@lcnr lcnr added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 28, 2022
@JohnCSimon
Copy link
Member

@b-naber
Ping from triage: Can you please post the status of this PR? I see merge there are merge conflicts.
Thank you.

@JohnCSimon
Copy link
Member

@b-naber
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you force push to it, else you won't be able to reopen.
Thanks for your contribution.

@rustbot label: +S-inactive

@JohnCSimon JohnCSimon closed this May 7, 2022
@rustbot rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label May 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants