@smyrman Thanks for the ack.

Question about step:? Why are these important? Is it simply to identify when to evaluate?

They seem to add a lot of visual noise. Why not instead just evaluate whenever err is changed?

@mikeschinkel, yes, an explicit point for where to reevaluate the condition is the point of step.

Why not instead just evaluate whenever err is changed?

It might work for the error case, but not sure it would work well for every case as break is suggeted as a general statement. A Condition can be anything, so you would need to know about all the variables used in the condition to know if revaluation should be done or not. It could also be that recalculation is expensive, or that you only want to do it at safe intervals.

Here is an example where assignment evaluation would not be enough:

func f(deadline time.Time) (*Result, error) {
	var err error
	var r *Result

	break err != nil || deadline.After(time.Now()) {
	step:
		r, err = Step1()
	step:
		r, err = Step2(r)
	step:
		r, _ = Step3() // let's imagine it's not safe to abort here.
		r, err = Step4(r)
	step:
		return r, nil
	}
	if err == nil {
		return nil, ErrTimeout
	}
	return nil, fmt.Errorf("f failed: %s", err)
}


"A Condition can be anything, so you would need to know about all the variables used in the condition to know if revaluation should be done or not."

Maybe I am missing something, but it seems since the condition is placed in the break expression so the compiler could identify all variables affected and simply revaluate when those variables change?

"It could also be that recalculation is expensive, or that you only want to do it at safe intervals."

Those feel like an edge case that should be handled with explicit if statements rather than through a general purpose approach. IOW: "Make the common use case trivial, and the uncommon use cases possible."

For me the step: seems like something that the compiler could too easily do for me so I would rather have the compiler do it than burden me with having to do it at the appropriate times myself.

Maybe I am missing something, but it seems since the condition is placed in the break expression so the compiler could identify all variables affected and simply revaluate when those variables change?

When does time.Now() change?

"When does time.Now() change?"

@smyrman Give me a full example in how you would use it and I'll answer.

The general answer is every time it's run. The deadline in my example above is static, yet it expires because the result of time.Now() changes.

I don't see a way that the step can be avoided for this syntax. The collect suggestion in #25626 don't need the step keyword because it's collecting only one variable and not allowing a generic condition check. I think this is a trade-off. You can avoid the step keyword with the semantics of the collect statement, or you can have a generic conditional check and not be able to avoid it.

I do think you have helped me come up with more use-cases where this statement could potentially be useful, other than error handling:

• periodic deadline calculation
• progress bar updates
• all of the above

func f(deadline time.Time) (*Result, error) {
	var err error
	var r *Result

	bar := pb.StartNew(4) // https://github.com/cheggaaa/pb
	break err != nil || deadline.After(time.Now()) || bar.Increment() == 3 {
	step:
		r, err = Step1()
	step:
		r, err = Step2(r)
	step:
		r, _ = Step3()
		r, err = Step4(r)
	step:
		return r, nil
	}
	if err == nil {
		return nil, ErrTimeout
	}
	return nil, fmt.Errorf("f failed: %s", err)
}


I think you want break if Condition

However I much prefer the collect/try construct which you've branched this from.

@smyrman Sorry, I did not realize your OP included an example. I was multitasking and so was not careful enough.

I think, as you are realizing, what started as a solution for tedious error handling is trying to become a general purpose construct. It might be trying to do too much. But I'll humor you and assume it makes sense to do this route. (Ironically, even though @networkimprov doesn't like this proposal, his comment helped me conceptualize what you are trying to do.)

If the break condition includes a variable comparison, it evaluates when the variable changes. If the condition contains a function call it is also evaluates on every assignment, every control structure condition evaluation and upon every return from a func call, but only once if the return is also an assignment or a control structure condition evaluation.

And if the condition is time consuming then you should restructure your code so that you do not use a time consuming condition with this construct. Instead, use an if statement where you want to evaluate it.

@networkimprov Would you mind elaborating as to why you like the collect/try construct better?

Just my two cents so take it as you would like but I think it's an unneeded feature.
That being said, I don't think step actually adds anything if there was a break if cond added to the syntax other than make it kinda hard to read.

Furthermore, if step isn't implemented then why do a break if cond? It's essentially a different method of checking return values after function invocation which to me doesn't flow very well.

I suppose the separate lines with step annoy me. Maybe this tho...

break if err != nil {
try a, err = f1()
b = f2() // can't break
try c, err = f3()
}

Also I want a way to flag fatal errors and indicate a fatal error handler...

I think the syntax could be in many different ways, and is probably not an important part of the proposal. I want to show a syntax so you can relate to the feature. The important part of the proposal is what it says on the top:

The proposal is to add syntax to the Go language to support the cases where you want to repeat the same Condition check for several different StatementLists. This is in opposition to the ForStmt where you want to repeat both the Condition check and the StatementList.

See the Go spec for details, as it does a great job of explaining those statements once you understand the declaration language.

Maybe it would make sense to steel even more from the ForStmt, includingrange support, initial assignment and post "loop" execution.

If the break condition includes a variable comparison, it evaluates when the variable changes. If the condition contains a function call it is also evaluates on every assignment, every control structure condition evaluation and upon every return from a func call, but only once if the return is also an assignment or a control structure condition evaluation.

I feel that is getting pretty complex, but maybe it's implementable. I still feel the collect proposal is more suitable for "automatic" recalculation.

"I feel that is getting pretty complex, but maybe it's implementable. I still feel the collect proposal is more suitable for "automatic" recalculation."

Optimizing complexity is part of what a compiler does. So I think it is very doable, unless someone better at compilers than me can point out why not.

This is not merely alternate keywords; try indicates where condition is tested after results are computed. I can't tell where it's tested in the OP.

break if err != nil {
try a, err = f1() 
b = f2() // can't break
try c, err = f3()
}

And syntax strongly affects the reactions of your audience, so make it appealing sooner than later.

And syntax strongly affects the reactions of your audience, so make it appealing sooner than later.

I agree, but I am not sure, if the proposal is accepted, that a syntax should be included other than to serve as an example.

Lets talk about the syntax, which I claim is not important. This is a completely different syntax that still implements the same proposal text:

Let's say we added a repeat keyword as an alternative to else in the IfStmt that simply repeats the previous check:

func f(deadline time.Time) (*Result, error) {
	var err error
	var r *Result
	if err == nil && deadline.Before(time.Now()) {
		r, err = Step1()
	} repeat {
		r, err = Step2(r)
	} repeat {
		r, _ = Step3()
		r, err = Step4(r)
	} repeat {
		return r, nil
	}
	if err == nil {
		return nil, ErrTimeout
	}
	return nil, fmt.Errorf("f failed: %s", err)
}


This gives a completely different feal. Syntax matters when it's implemented, but before that we need to know if the semantics makes sense, because if they don't, the syntax won't neither.

Be aware that many gophers are adamant about the necessity of 3 lines of ceremony after each function call, and do not agree that it hurts readability. #22122

I like what you're trying to do, but you have to explain how people are dying (suffering is insufficient) under the current regime if you hope to change it.

And again, it is not clear in the OP when the condition is tested. I tried to clarify that with my use of try above.

Sure, your syntax example is perfectly fine, and woul implement the proposal.

Proposed

func f() (*Result, error) {
	var err error
	var r *Result

	break err != nil {
	step:
		r, err = Step1()
	step:
		r, err = Step2(r)
	step:
		r, _ = Step3() // ignore errors here
		r, err = Step4(r)
	step:
		return r, nil
	}

	return nil, fmt.Errorf("f failed: %s", err)
}

vs current

func f() (r *Result, err error) {
	if r, err := Step1(); err != nil {
		return nil, fmt.Errorf("f failed: %s", err)
	}

	if r, err = Step2(r); err != nil {
		return nil, fmt.Errorf("f failed: %s", err)
	}

	r, _ = Step3(r) // ignore errors here...
	if r, err = Step4(r); err != nil {
		return nil, fmt.Errorf("f failed: %s", err)
	}

	return r, nil
}

@cznic, see this for an example of current: #25626 (comment)

Also see my comment above for a better example of proposed.

Did a large update of the description, also included your example syntax @networkimprov.

Also added a new example syntax that extends the for-loop by adding a continue> statement as in "continue here". The idea would be to iterate the for loop, but then continue at the location in the code where the continue> statement is places.

This allows for all of the semantics contained int the first syntax example, and more.

Again, all of this seems like adding unnecessary complexity to the language when the same could be achieved with much simpler syntax. I look at the proposed syntax and just them very hard to grok compared with how we can already code today in Go. I'd much rather see existing syntax used with some added semantics and put the burden on the compiler to sort it out rather than burden the developer with all this. #fwiw #jmtcw

Some meandering observations.

One nice thing about this vs many of the error handling proposals is that the checkpoints are clear and explicit.

The semantics of the repeated evaluation isn't fully specified, e.g. around variable scoping and binding. But it seems like the intent is that it operate in a roughly closure-like manner. And indeed, if you were trying to de-sugar this programmatically, one natural way is with closures:

break E {
  S1
step:
  S2
step:
  S3
}

translates to:

var exit bool
f := func() {
  exit = E
  if exit {
    panic(0) // value unimportant 
  }
}
func() {
  defer func() {
    if exit { recover() }
  }
  S1
  f()
  S2
  f()
  S3
}()

(This isn't quite perfect, because if Sx panics, the stack trace will be slightly different. But it is close.)

And with the repeat syntax in #27075 (comment), this translation is even easier: just make the closure return a bool.

There's one thing you can't do in a closure, which is cause the calling function to return and provide its return values. And there's no obvious way to add such a thing, and you wouldn't want to; local control flow is better.

I like those observations @josharian. This started as syntactic sugar for closures, and perhaps that's all this is.

On the same note, isn't switch-case just syntactic sugar for if/else semantics though? Yet I find the type switch one of the really useful features of the go language.

I thing that the syntax suggestion that is furthest away of just providing syntactic sugar, is probably the continue> (continue here) extension to the for-loop, but that's because that suggestion offers additional semantics. I am still not sure if such an extension would increase readability and be tremendously useful, or increase language complexity without any of those benefits.

The draft proposal in https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md seams much better suited for error handling than this proposal.

I am closing it.

Thank you for opening this, it is a worthy idea, and should have seen at least as much support as the proposal you branched from.

I am developing a revision of the check/handle concept, the #id/catch Error Model #27519.