#60720

Similar, except for introduction of new keyword

Well the main difference is that this doesn't call a function but injects a switch block in predictable locations.

Also this is intended to be purely at compile time only.

This makes the question if a variable has a trap or not decidable at compile time.

What about assignments through pointers, and additionally in other functions?

p := &err
if ... { *p = ... }
maybeAssignToArg(p)

See also #56258.

Assignments in other functions would not have the trap appended. Assignments through a pointer would but only if the variable named in the trap is a pointer. The trap block is injected only if there is a = or := statement. So @randall77 in your examples no trap block is injected unless if there also is a select block for p. The assignments are though the p variable not through the err variable. Like this this proposal remains a pure compile time text expansion that is easy to understand.

The difference with the other proposal is that the trap is installed explicitly and statically on a named variable, not on the _ variable.

So

var err error
select err { ... } // set up a trap
err = ... // this traps
*(&err) = ... // this doesn't trap

?

That does trap because err is mentioned explicitly. That is the point of this proposal, everything is explicit! :) Of course doing *(&err) is a bit obtuse.

Edit:
And in case err is a struct err.Field = blah does inject the trap since err is mentioned.

That does trap because err is mentioned explicitly.

err is mentioned, but there is never an explicit assignment to it. Perhaps this example is better:

p := &err
*p = ...

For extra fun , add arbitrary other complications between the two statements, like

p := &err
if ... { p = ... something else ... }
*p = ...

The general point is that at any pointer assignment, how do you tell whether it is assigning to a trapped variable or not?
I think the only possible answers are "we have to check it at runtime somehow" or "assignments through pointers don't trap".

Then it is "assignments through pointers don't trap". The idea is that the trap is strictly compile time and nominal only, which makes it a lot simpler to implement than, say, a defer statement for which Go has to keep a runtime list.

As I see it it will still be very useful even with these restrictions.

Edit: this is also how it this proposal is different from simply using a defer() statement for error handling as we can already do with the help of generics e.g. this comment: #57645 (comment)

Is the panic here "trapped" or "untrapped"?

var err error
f := func() { err = io.EOF }
select err {
case err != nil:
    panic("trapped")
}
g := func() { err = io.EOF; panic("untrapped") }
f()
g()

Is the panic here 1 or 2? What gets printed before the panic?

var err error
select err {
case err != nil:
    println(1)
    panic(1)
}
select err {
case err != nil:
    println(2)
    panic(2)
}
err = io.EOF

The anonymous func is a separate scope so untrapped. The second trap block overwrites the first one so for the second example it is 2 only.

Based on the discussion above, and the similarity to earlier declined issues, and the emoji votings, this is a likely decline. Leaving open for four weeks for further comments.

Thanks for considering this. While this proposal does not seem to be what we need, maybe it will help finding a better idea for error handling by elimination.