You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Last time I looked at Rust, they had a try! macro for this, but now they have a ? postfix operator; if "postfix" isn't stretching the terminology a bit here. (Note to self: check if it's actually implemented as a postfix ? in the parser, or whether it's the call syntax rule that has been extended. Either would work, but from slightly different directions in the grammar.)
Similar to #13, this operator affects the rest of the execution, but unlike that issue, it does it by returning early.
We don't have a Result type like Rust does; it's an open question how much such a type would require a static type checking mechanism.
The text was updated successfully, but these errors were encountered:
I feel like this brings us back to the discussion on whether or not you should be able to use a return from a quasi; and that it should return from the function the quasi is injected into.
Dammit! At first blush, you're right! It's here and now that my stubbornness on that issue is coming back to bite me...
I feel that, if I start turning over one stone here, I'll end up turning over them all (again) — which may or may not be worthwhile. So for the moment, let me just agree with you @vendethiel, with absolutely no further strings attached.
I feel that, if I start turning over one stone here, I'll end up turning over them all (again) — which may or may not be worthwhile.
No, it seems I was already convinced in the past, as evidenced by #483. We just haven't Made It So yet. So all's fine, and return will return from whatever's in the mainline, not in the macro.
Last time I looked at Rust, they had a
try!
macro for this, but now they have a?
postfix operator; if "postfix" isn't stretching the terminology a bit here. (Note to self: check if it's actually implemented as a postfix?
in the parser, or whether it's the call syntax rule that has been extended. Either would work, but from slightly different directions in the grammar.)Similar to #13, this operator affects the rest of the execution, but unlike that issue, it does it by returning early.
We don't have a
Result
type like Rust does; it's an open question how much such a type would require a static type checking mechanism.The text was updated successfully, but these errors were encountered: