It makes it hard to read and follow the "Happy Path" of the code.

I disagree. It is easy to follow the happy path of the code. In well written Go code the happy path proceeds along the left hand side of the screen towards the bottom of the function.

The proposal makes the "normal" control flow (not including panics) that previously was easy to detect by looking at return statements now hidden. Any assignment to a variable that is under "watch" can now exit the function.

This proposal I think shares similar properties with the check/handle proposal listed in #40432
The check part in this proposal instead of explicit is implicit on every variable assignment.

There also a bunch of open question about behaviour that would need to be clarified:

• do map deletes or the copy builtin trigger the watch?
• what if a pointer to a variable is passed into another function. Is changing the value of the variable then triggering the watch even while in the other functions?
• does another watch trigger when a value is assigned to a variable that is watched inside the watch itself?
• can multiple watches be defined in a function?
• can multiple watches be defined on the same variable?
• are variable assignment in defers still watched? what defers are still executed if a watch triggers in defer?
• what happens if a function closure is returned containing an assignment to a watched variable? Is the watch still active in the closure when returned or passed to a leave function, when called in the same function?
• for multiple assignments (f1, f2 = ....) and a watch on f1, f2. Is the watch triggered once or twice?

The proposal makes the "normal" control flow (not including panics) that previously was easy to detect by looking at return statements now hidden. Any assignment to a variable that is under "watch" can now exit the function.

This proposal I think shares similar properties with the check/handle proposal listed in #40432
The check part in this proposal instead of explicit is implicit on every variable assignment.

Thanks for your feedback! I thought about this, and you are right. Its way better to make it explicit, so I changed my idea and updated my comment.

With my change, most of your concerns are adressed:

There also a bunch of open question about behaviour that would need to be clarified:

• do map deletes or the copy builtin trigger the watch?

No

• what if a pointer to a variable is passed into another function. Is changing the value of the variable then triggering the watch even while in the other functions?

No

• does another watch trigger when a value is assigned to a variable that is watched inside the watch itself?

No, watch assignments must be in the same function as the watch.

• can multiple watches be defined in a function?

Yes, I don't see why not. Same as with defer, they could run LIFO or FIFO.

• can multiple watches be defined on the same variable?

Yes.

• are variable assignment in defers still watched? what defers are still executed if a watch triggers in defer?

No, defer runs a different function, plus the watch ends before defer runs

• what happens if a function closure is returned containing an assignment to a watched variable? Is the watch still active in the closure when returned or passed to a leave function, when called in the same function?

No, watch ends before defer and the updated idea requires the watch assignment in the same function as the watch.

• for multiple assignments (f1, f2 = ....) and a watch on f1, f2. Is the watch triggered once or twice?
  That would run once (per watch assignment)

With my change, most of your concerns are adressed:

To me now it looks even more like the abandoned handler/check proposal: https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md

Could you please clarify what the main differences are that makes this proposal stand out it utility and avoiding problems vs the above proposal. This would help the discussion about the intent of the proposal and not reintroducing proposals that are (apart from minor details) the same. Minor details may be important so it is nice to understand the thought process behind them.

Has some similarities to #32795, #32804, #33002, #33266, and #33387.

In reply to @martisch

In brief, the check/handler proposal as drafted introduces:

• A check applies to an expression of type error or a function call returning a list of values ending in a value of type error
• Handler(s) is/are invoked with the error, in reverse order of their declaration
• A default handler is avoiding the infamous if err != nil { return err }

So yes, the idea of watch is quite similar, but I see some advantages:

• watch is not limited to errors. Personally i think this is a big advantage, think of easier debug code etc...
• If we introduce check/handler we are leaving the path that errors are just values, it turns errors in something which is specially treated leaving simplicity behind
• watch is not magically checking the last return value of a function, here the check/handler proposal turns the convention (to use error as the last return value) into a requirement, don't know if that is a good thing
• watch lets you watch multiple variables at the same time and exactly declare them
• The scope of the watch block is like with any other block (e.g. if), so it is not called with the only parameter error like the handler is
• watch acts more like a goto in your code and thus is a imho easier to read understand and follow
• check/handler introduces two new keywords whereas watch is only one
• check may change your code flow and return right after that line were its in, and so does !=. but since the exclamation mark by definition tells you to pay attention, i find it easier to remember to be aware of the fact that the function might be left after the execution of that line.

Thanks for the list of other proposals @ianlancetaylor, let me quickly summarize them to get a better understanding of the watch proposal.

#32795 with...handle...

• two new keywords with and handle
• puts the happy code one indent to the right
• proposal was closed

#33002 check...handle

• think try...catch without the throw 🧐
• confusing syntax, something is checked which is not assigned... even after reading the proposal the third time I did not really get it
• proposal was closed

#32804 expect

• looks like watch with the condition built-in
• has the problem that whenever err changes expect is checked (like watch without !=)
• not easy to understand if you don't know what it does
• proposal was closed

#33266 on

• Like proposal: Go 2: simplify error handling with expect #32804, same problem (checking err is implicit)
• proposal was closed

#33387 try...except

• Like gccgo: gcov branch coverage doesn't look quite right #3302, same problems
• Proposal was closed

So basically, I can see two groups here, one is introducing two keywords (with the indented code problem) and with the implicit error checking problem (#33002 is even doing an implicit secret check of a otherwise voided return value), and the other group where we have some sort of keeping an eye on err, but implicitly.

After reading all of the other proposals, I noticed most of them use an example CopyFile, so I tried how watch would look like here:

func CopyFile(src, dst string) (err error) {
        var r, w *os.File

        watch err {
             if err != nil {
		return fmt.Errorf("copy %s %s: %v", src, dst, err)
	    }
        }

	r, err != os.Open(src)
	defer r.Close()

	w, err != os.Create(dst)
	if _, err := io.Copy(w, r); err != nil {
		w.Close()
		os.Remove(dst)
                 err != err
                 // err != errors.Wrap(err, "Copy") is an alternative
	}

	if err := w.Close(); err != nil {
		os.Remove(dst)
                 err != err // same as in the original example
                 // err != errors.Wrap(err, "Close") is an alternative
	}
}

• The err != err is weird, but why not, the != allows you to easily decorate the error instead with more info
• Maybe we can allow :!= or change != to =! and allow :=!, saving the declaration of r and f

It does not seem like a good idea to reuse !=, which is a binary operator, for an assignment statement. In fact, I don't think we can do it, because a != f() is already a valid expression statement, albeit one that doesn't do anything.

In effect it seems that this proposal is using != as something like the try expression in #32437, with the addition of a handler. So similar complaints arise: this proposal lets code change the flow of control in an obscure way without using a keyword.

The differences between this proposal and earlier proposals that were declined seem fairly subtle.

Based on the discussion above, this is a likely decline. Leaving open for four weeks for final comments.

It does not seem like a good idea to reuse !=, which is a binary operator, for an assignment statement. In fact, I don't think we can do it, because a != f() is already a valid expression statement, albeit one that doesn't do anything.

In effect it seems that this proposal is using != as something like the try expression in #32437, with the addition of a handler. So similar complaints arise: this proposal lets code change the flow of control in an obscure way without using a keyword.

The differences between this proposal and earlier proposals that were declined seem fairly subtle.

I changed my proposal to use =!.

For what it's worth =! is also ambiguous, as ! is a unary operator. a =! b is a valid Go statement today.

I think you guys are right and I like to retreat my proposal. I liked the idea to have a „jump to“ block like „watch“, but it needs a clearer code path when called.

Maybe the idea to treat errors as values is the right way to do. After all I guess we all got used to it anyway over the last years...