Skip to content
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

C-QUESTION-MARK: Examples use ?, not try!, not unwrap #2811

Closed
Tracked by #2495
bugadani opened this issue Dec 13, 2024 · 3 comments
Closed
Tracked by #2495

C-QUESTION-MARK: Examples use ?, not try!, not unwrap #2811

bugadani opened this issue Dec 13, 2024 · 3 comments
Assignees
Labels
1.0 non-breaking Not needed for 1.0 and can be supported without breaking the driver. peripheral:uart UART peripheral

Comments

@bugadani
Copy link
Contributor

No description provided.

@bugadani bugadani mentioned this issue Dec 13, 2024
42 tasks
@tom-borcin tom-borcin added 1.0 non-breaking Not needed for 1.0 and can be supported without breaking the driver. and removed 1.0-blocker labels Dec 17, 2024
@playfulFence playfulFence self-assigned this Jan 9, 2025
@playfulFence
Copy link
Contributor

Last night I wanted to end the day with this issue as a quick win, but something went wrong....
image

Turns out, using ? is not so easy in the context of our drivers - we simply don't return an error from main.
@bugadani tried to make a solution for this (thanks)((it's shown in the screenshot below))
image

It seems to me that at this point there's not much point in fighting over the use of ? in our case.

  1. The solution to this problem for the documentation is already very cursed by itself
  2. ? is not applicable in the context of the main function in our driver, so the doc example will make no sense.
  3. This Rust API guideline uses “should” wording, which means that it's not a strict prescription.

With everything said above, I would prefer to close the C-QUESTION-MARK related issues. I look forward to your opinions!

@bugadani
Copy link
Contributor Author

? is not applicable in the context of the main function in our driver, so the doc example will make no sense.

I think this is the deciding factor. The fn main() -> Result<(), Box<dyn Error>> pattern doesn't apply to us, and the user has to work pretty hard if they want it. If someone can come up with a solution like in the screenshot, they can also replace unwraps in an example.

@playfulFence
Copy link
Contributor

Closing this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.0 non-breaking Not needed for 1.0 and can be supported without breaking the driver. peripheral:uart UART peripheral
Projects
Archived in project
Development

No branches or pull requests

3 participants