~sircmpwn/hare#461: 
To ignore errors, use _ = expr rather than expr: void

After we add this, we may want to consider disallowing casting arbitrary types to void, since it can cause some other issues.

Status
REPORTED
Submitter
~sircmpwn
Assigned to
No-one
Submitted
3 years ago
Updated
10 months ago
Labels
design harec spec

~ecs 3 years ago

Mild -1 to this unless we can come up with some other use cases for _. I think the only place we use this at the moment is in function parameters, and I'd like to drop it from there as well.

Another thing we could do is make _ a normal identifier and use let _ = can_error(); by convention.

~sircmpwn 3 years ago

I would prefer to make it a syntax thing in this case.

~sebsite 1 year, 9 months ago

+1, for two reasons: 1. _ is already used for tuple unpacking assignment, so it makes sense to generalize that to single-object assignment as well. 2. the ability to cast any expression to void is a special case that I think should really be removed (I assume this was just done because C allows this, but I don't think that's a good enough reason)

I agree that it's strange to have _ be a keyword but only for binding/assignment, but I don't think it's that big of a deal and I can't think of any better ideas.

~ecs 1 year, 9 months ago

+1, though we should still drop _ from function parameters

~smlavine 1 year, 6 months ago

(acknowledging this is a very old issue)

I think that : void to ignore errors makes for readable code, since it usually replaces !, ?, or as, all syntactically found at the end of the function call, same as : void. Given these I think it makes sense to keep it.

~sebsite 1 year, 5 months ago

We can split this into two parts if there's still disagreement about disallowing void casts: we should definitely allow _ = expr, even if for no other reason than consistency with tuple assignment. I still think disallowing void casts is the correct thing to do, though.

Worth noting that using a cast to ignore errors would still be possible without void casts (so long as the expression's result isn't used), by just casting to the non-error type (or tagged union of non-error types).

{
    fmt::println("idc about errors"): size;
};

Though I feel like this should be discouraged.

~xha 10 months ago

+1 for me too because this would be a nice thing to have in for-each loops where you just care about the length of an array and not of the elements that it has itself. seen that a couple of times in the stdlib already. so i.e.

for (let _ .. [1, 2, 3]) {
        do_thing();
};

~xha 10 months ago

btw, this should probably be an RFC?

~sebsite 10 months ago

Yeah this ticket predates the RFC process, but it should be an RFC yeah.

As for for-each loops: the proposal here is to re-use the assignment syntax, not the binding syntax. I guess we could allow both though? Not sure.

~sebsite 10 months ago

I guess allowing the binding syntax also makes sense, for consistency with tuple unpacking bindings

~xha 10 months ago

i think _ = <expr> is kinda weird and should probably just be let _ = <expr>? anyways, yeah, it'd be nice if we could allow both, also for consistency.

Register here or Log in to comment, or comment via email.