Yeah, I see. One example I had in mind was items.removeLast() which returns the item which would have to be silenced with _ = if it's unwanted.
In case of your example it could be silenced with try! continuation.yield(42).checkResult() to not get that throw propagated outside (with the side benefit that if it does throw – you'd quickly know about that).
I'd love that as well... even to the point if discardableResults returning functions were not be able participating in the "single (or last) expression don't need return" machinery and require explicit return statements to make intent clear (as pitched here)
Thinking out loud: what if discardable was on type? And thus propagable along with the type..
Task { // inferred as Task<discardable Int, Never>
items.removeLast() // `discardable Int`
}
along with something akin to:
extension Task where Success is discardable, Failure == Never {
@discardableResult init(...) { ... }
}
Existing precedents from other languages of embedding discardability in types
struct [[nodiscard]] SomeType {
int x;
};
SomeType foo() {
return SomeType();
}
void bar() {
auto proc = []{ return foo(); };
proc(); // 🔶 Warning: Ignoring return value of function declared with 'nodiscard' attribute
}