Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

benchmarking v2 syntax is confusingly lax about return types, leading to confusion #13278

Closed
Tracked by #264 ...
sam0x17 opened this issue Jan 30, 2023 · 0 comments · Fixed by #13224
Closed
Tracked by #264 ...

benchmarking v2 syntax is confusingly lax about return types, leading to confusion #13278

sam0x17 opened this issue Jan 30, 2023 · 0 comments · Fixed by #13224
Assignees
Labels
U2-some_time_soon Issue is worth doing soon. Z1-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder

Comments

@sam0x17
Copy link
Contributor

sam0x17 commented Jan 30, 2023

The benchmarking v2 syntax allows any return type on benchmark function definitions. We should probably only be allowing () (blank return type) or Result<(), BenchmarkError> in scenarios where the programmer wants to use the ? operator somewhere in the benchmark function body.

After talking about this with @ggwpez we thought it would make sense to require a return type of Result<(), BenchmarkError> in scenarios where the programmer uses the ? operator within the function body, and also allow a blank () return type. Any other return types on the benchmark function definitions would trigger a compiler error. Doing things this way will make the benchmark function defintion feel more like a real function and will make people more aware that they can use ? in these contexts (and avoid the confusing situation where someone writes ? and it compiles even though what appears to be the enclosing function def does not have a Result or Option return type).

Open to any thoughts people may have, though!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
U2-some_time_soon Issue is worth doing soon. Z1-easy Can be fixed primarily by duplicating and adapting code by an intermediate coder
Projects
Status: Done
1 participant