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
I have noticed that, in some contexts, captures can be omitted. Check out this example:
constv: error{A}!i32=error.A;
if (v) |_| {} else|_| {} // explicitly ignoring the values capturedif (v) {} else {} // the captures are completely omitted, yet this still works
Not only this makes it so there are two different ways to ignore a capture, but sometimes this can also contribute for the programmer to completely forget the variable. If #335 gets implemented, simply not capturing the variable (which could happen due to forgetting to type the capture) would probably not result in unused identifier errors/warnings.
Here is a list of places where I tried to analyze these captures:
test"capturing and ignoring on an optional value" {
// This one seems to work pretty much as this proposal suggests.constval: ?i32=null;
// :: Explicitly ignoring the capture// Compiles successfully (as wanted)if (val) |_| {} else {}
// :: Ommiting the capture// Does not compile, although the error is somewhat cryptic. I might be interpreting it wrong...if (val) {} else {}
}
test"capturing and ignoring on an error union" {
constval: error{A}!i32=error.A;
// :: Explicitly ignoring both capturesif (val) |_| {} else|_| {}
// :: Explicitly ignoring only the error capture// This works fine - with this proposal, it shouldn't.if (val) {} else|_| {}
// :: Explicitly ignoring only the success capture// Hmm... this one errors out, but because the compiler thought we were trying to capture an optional value.if (val) |_| {} else {}
}
test"forgetting to capture on a for loop" {
constarr: [5]u8= [_]u8{ 1, 2, 3, 4, 5 };
// This one hopefully does not compile already, although it complains about `{` being an invalid token. Maybe a// clearer error (a note maybe?) could be shown here ("missing capture").for (arr) {}
}
test"capturing and ignoring on a while loop" {
// Just a sample struct to iterate from 0 to 4.constTo4Iterator=struct {
i: u8=0,
fnnext(self: *@This()) ?u8 {
if (self.i<5) {
self.i =1;
returnself.i-1;
} else {
returnnull;
}
}
};
varit=To4Iterator{};
// Works as expectedwhile (it.next()) |_| {}
// Hopefully this doesn't work, but, as the other errors, the one from here is kind of unclear and might not be for this reason.while (it.next()) {}
}
The text was updated successfully, but these errors were encountered:
Currently the behavior on if and while is that no captures makes the conditional boolean, capture after the condition makes it an optional and a capture after else makes it an error union. for works differently always requiring a capture after the condition and never allowing one after else.
// This works fine - with this proposal, it shouldn't.
Here's Andrew's current proposal to how this should work #6060 (comment).
The cryptic errors should improve once stage2 is ready.
I just noticed though that I forgot to mention catch - are there any plans to make the capture obligatory there?
At least on my version (0.8.0-dev.1482 6787f163e) the behavior is kind of strange:
fndoSomething() error{A}!void {}
test"catch tests" {
// This seems to be the current way to ignore an error.doSomething() catchunreachable;
// This causes a compile error, and a rather strange one://// "error: unused variable: '_'"//// Is it using `_` as a normal identifier..?doSomething() catch|_|unreachable;
}
Also, I do think that catch without a capture could be used for error types with only one variant, but I'm not sure if that would be the best way to express that. It would be nice though, because you then wouldn't need to type an entire catch |err| switch (err) { error.A => { doThing(); } } and at the same you wouldn't risk ignoring other possible errors added on the future.
Should I make this another proposal, though? I think I might be going off a tangent here.
alexnask
added
the
proposal
This issue suggests modifications. If it also has the "accepted" label then it is planned.
label
Apr 1, 2021
@andrewrk Does the closure mean it's been rejected or implemented? Since some stuff was already in the works (#6060, as previously mentioned) I'm not sure about what has been decided here.
I have noticed that, in some contexts, captures can be omitted. Check out this example:
Not only this makes it so there are two different ways to ignore a capture, but sometimes this can also contribute for the programmer to completely forget the variable. If #335 gets implemented, simply not capturing the variable (which could happen due to forgetting to type the capture) would probably not result in unused identifier errors/warnings.
Here is a list of places where I tried to analyze these captures:
The text was updated successfully, but these errors were encountered: