This looks like #46655, with check -> abort? and moving its position

1. Similar ideas have been proposed several times before.
2. This kind of approach means that reading the code focuses on error handling, because every line starts with abort?. That makes the code somewhat harder to read.
3. Early on you mention code that returns an annotated error, but I don't see any examples of such code using abort?.

1. Similar ideas have been proposed several times before.

Not sure what you mean by this. I'm aware of the history, but perhaps you mean it's not a technical issue?

From a technical perspective, I've seen the idea of returning from a function when an error is present, but the ones I've seen don't give the programmer much control of the values returned.

2. This kind of approach means that reading the code focuses on error handling, because every line starts with abort?. That makes the code somewhat harder to read.

Only lines that need to bail early would start with abort? so it wouldn't be every line. Every line that starts with abort? also signals intent so it's information dense.

3. Early on you mention code that returns an annotated error, but I don't see any examples of such code using abort?.

func (d *decodeState) unmarshal(v any) error {
	rv := reflect.ValueOf(v)
	if rv.Kind() != reflect.Pointer || rv.IsNil() {
		return &InvalidUnmarshalError{reflect.TypeOf(v)}
	}

	d.scan.reset()
	d.scanWhile(scanSkipSpace)
	// We decode rv not rv.Elem because the Unmarshaler interface
	// test must be applied at the top level of the value.
	err := d.value(rv)
	if err != nil {
		return d.addErrorContext(err)
	}
	return d.savedError
}

// With abort?
func (d *decodeState) unmarshal(v any) error {
	rv := reflect.ValueOf(v)
	if rv.Kind() != reflect.Pointer || rv.IsNil() {
		return &InvalidUnmarshalError{reflect.TypeOf(v)}
	}

	d.scan.reset()
	d.scanWhile(scanSkipSpace)
	// We decode rv not rv.Elem because the Unmarshaler interface
	// test must be applied at the top level of the value.
	abort? d.value(rv); d.addErrorContext(err)
	return d.savedError
}

First clause is checked for errors, last clause is what's returned.

@seankhliao I don't see the similarity with #46655

check works on singular values and hooks into named return values, meaning the return is implicit.

abort? works on lists of values and has an explicit list of return values. One of the examples above also shows how abort? helps get rid of named return values (shown here for reference):

// Before
func (t *multiWriter) Write(p []byte) (n int, err error) {
	for _, w := range t.writers {
		n, err = w.Write(p)
		if err != nil {
			return
		}
		if n != len(p) {
			err = ErrShortWrite
			return
		}
	}
	return len(p), nil
}

// After
func (t *multiWriter) Write(p []byte) (int, error) {
	for _, w := range t.writers {
		abort? n, err := w.Write(p)
		if n != len(p) {
			return n, ErrShortWrite
		}
	}
	return len(p), nil
}

I'm sympathetic to Ian's second point above:

This kind of approach means that reading the code focuses on error handling, because every line starts with abort?

I wonder whether this concern would be alleviated by using a postfix expression instead of the abort? prefix, so that the left-hand side of the code would not be cluttered with error-handling.

Rust underwent a similar transformation in its error handling functionality when it introduced a postfix question mark operator. Instead of saying try!(foo()) one could write foo()? to early-return with an error result.

This discussion also reminds me a bit of Jonathan Amsterdam's 2017 talk on Errors as Side Notes about formatting code to place all error-handling code to one side, so that the main-line control flow can be more easily understood:

Similar ideas have been proposed several times before.

Not sure what you mean by this. I'm aware of the history, but perhaps you mean it's not a technical issue?

What I mean is: we've rejected similar ideas in the past. I agree that as far as I know this exact idea has not been proposed before.

abort? d.value(rv); d.addErrorContext(err)

Thanks for the example. This is quite different from other Go language constructs.

Rust underwent a similar transformation in its error handling functionality when it introduced a postfix question mark operator. Instead of saying try!(foo()) one could write foo()? to early-return with an error result.

Rust's ? operating is interesting, but I think it only works because the Result type is a tagged union. The ? operator doesn't have to bother with figuring out what to return for the Ok value when you exit. Any time you return from a Go function there could be multiple return values and you need a way (and room) to specify the other values. You could always assume zero values, but that might be too limiting in some scenarios where partial results apply.

I think it almost has to be on the left-hand side if you are going to return multiple values.

I was imagining that code currently written like this:

err := d.value(rv)
if err != nil {
	return d.addErrorContext(err)
}

could be written as something like this:

err := d.value(rv) returniferror d.addErrorContext(err)

where the semantics of returniferror are similar to those of abort? but with the keyword placed syntactically after the expression.

I am not actually proposing this since I don't think I have internalized the Go design sensibility quite yet, but I found it interesting to think about.

I think a specific challenge with this particular genre of proposal is that there have been two different levels of disagreement interleaved in all of the previous discussions I've seen:

1. Those who disagree with specific details of the proposal, such as exactly which new keywords/symbols to use, and what order they would go in.
2. Those who disagree that eliminating the if statement and its indented block is even a desirable goal at all, regardless of the fine details of exactly how the proposed "shorthand" is shaped.

(Note: I am not arguing either of those points here. For the sake of this comment, I'm neutral on the specific proposal in this issue.)

I think some of the "this is similar to previous proposals" reaction might be thinking about it from the perspective of the second kind of objection: those who expressed that they don't think this sort of goal is even desirable see this proposal as equivalent to all of the others because all it's changed is some irrelevant (to them) details about where on the line each clause goes and what delimits them.

I think all proposals for shorthands to avoid writing a normal if statement seem doomed to this outcome: it's unclear exactly what the rejection of the previous proposals represents -- whether it's a rejection of form 1 or form 2 above, or something else entirely -- and so therefore it's unclear whether a new proposal like this one constitutes "new information" to justify revisiting an earlier decision.

Perhaps it would be helpful to have a broader discussion (in a different place than this one issue) about what parts of "the error handling problem" seem to have sufficient consensus for it to be worth proposing solutions, what parts the proposals group feels have been retreaded enough to rule as "decided", and what parts of the problem space remain murky and perhaps in need of further problem-space research.

1. 类似的想法以前已经多次提出过。
2. 这种方法意味着阅读代码侧重于错误处理，因为每一行都以 开头。这使得代码更难阅读。abort?
3. 早些时候，您提到了返回带注释错误的代码，但我没有看到任何使用 .abort?

@apparentlymart Thanks for the comment but I don't entirely agree with you. I think there are objections to this specific proposal that go beyond "we don't need any syntax change."

1. Every error checking line starts with abort?, which buries the lede.
2. The proposed syntax for abort? returning an annotated error is visibly different from all other Go syntax.

I agree that it's very hard to satisfy everyone. But any syntactic change here would be the biggest change to the language other than generics. It would affect some 1% of all Go lines in existence. It really has to be an excellent change, not just adequate. And if we can't make it excellent, we shouldn't do it.

I'm sorry that I was unclear. I didn't mean to say that there are no legitimate criticisms of this proposal in particular, and for what it's worth I agree with the criticisms you shared and didn't mention them in my comment only because I was trying to make a broader point and wanted to separate it from my feelings about this proposal.

My comment was in response to the debate above about whether this is or is not a duplicate of a previously-rejected proposal. And in particular, that it's hard to say whether this is "different enough" from the previous proposals to constitute new information. It certainly isn't identical to any previous proposal, but it shares many characteristics with previous rejected proposals; it's unclear if what it shares are reasons for the previous proposals being rejected or not.

With that said, I can see that my comment could be read as dismissing all of the above dissent as being in my category 2. That was not my intention, and I apologize.

Sorry for misunderstanding.

i agree with you,it's good idea!!!

Every error checking line starts with abort?, which buries the lede.

I felt the same. Was abort? made a prefix to the statement to avoid grammar ambiguities ? Would it be better if we separated function invocation from error handling ?

E.g,

func getPlatformName() (string, error) {
   os, err := getOSName(); err?;
   arch, err := getCpuArch(); err?;
   return fmt.Sprintf("%s/%s", os, arch), nil;
}

where err? (which is just a regular statement) expands to

if err != nil {
   // Return zero values for all non-error arguments
   return "", err;
}

This may help remove clutter when simply bubbling up the error. If we want to add more context or wrap the error instead, use if err != nil like before. However, I'm not sure if the grammar can support syntax like above unambiguously.

P.S Please ignore it if this has been proposed & rejected before.

This kind of approach means that reading the code focuses on error handling, because every line starts with abort?. That makes the code somewhat harder to read.

TBH we are already in that boat. In most functions that do something interesting in go ~60-70% of lines concern error handling. Why is one keyword at the start more distracting than having to mentally skip the majority of the code lines when you are trying to read the flow of the happy path?

Having said that, a postfix notation would certainly be more helpful.

@doggedOwl

Why is one keyword at the start more distracting than having to mentally skip the majority of the code lines when you are trying to read the flow of the happy path?

I don't that's quite the right question. Exactly because so many lines of Go handle errors (though in my measurements it's not quite as high as you suggest), we have to be very careful about changing it. It will affect all existing Go code, which is a lot of code. And we really only get one chance at making a change: we can't keep changing so much code. So the question is not "is this proposal a bit better?" It's "is this the best possible proposal? Are there any possible problems with it that we may regret later?"

I do agree about it perhaps not being the most important question, but to try to answer it anyway:

In today's Go, the error handling and the "happy path" are typically separated onto separate lines, so that when scanning along the left edge of the code a sighted reader can (with some practice) mentally ignore the error handling boilerplate when interested in the happy path, or can pay attention to the one-level-indented blocks when interested in the error handling.

This possibility is also what motivates some parts of idiomatic Go style, such as preferring to put the error paths inside nested blocks and "happy path" code at the top-level, and using the if err := whatever; err != nil { form sparingly to avoid "hiding" the whatever behind the if keyword.

Putting the action being taken and the error handling on the same line effectively forces prioritizing one over the other, because only one thing can be first on a line. I think it's valid to debate whether the happy path and error handling should be combined onto a single line at all for this reason, but if you accept that as okay then it's also valid to debate whether the error handling or the happy path should appear first, since one will necessarily be harder to quickly scan than the other.

In previous proposals of this genre I think we've seen three broad variations:

1. Keep the happy path and the error path separated on separate lines, but reduce the number of lines used by the error path, typically to only one additional line.

   For example:

   err := DoSomething()
   return fmt.Errorf("doing something: %w") if err != nil

   Other variations in this category have made that second error-handling line begin with something that's unique only to error handling -- rather than a normal statement like return here -- to preserve (and possibly enhance) the ability to visually scan the left edge to quickly filter in or out the error-handling lines depending on one's goal when reading.

2. Combine both onto the same line and prioritize the happy path first.

   For example:

   err := DoSomething(); if err != nil return fmt.Errorf("doing something: %w", err)

   (Typically proposals of this form have also tried to simplify further, such as making the err symbol implicit rather than explicit, but I'm only talking about the relative positioning of the different parts of the code so I've intentionally left everything explicit here.)

3. Combine both onto the same line and prioritize the error-handling aspect, as is the case for this proposal.

Given that each of these options makes a different compromise, it seems like these are material differences that contribute to making a particular proposal unique from others, rather than just details that could be figured out later after accepting the proposal.

Assuming that reducing the amount of code spent on error handling is a goal (which, as I was noting earlier, also seems to be a broader point of disagreement), it does still seem important to consider the fine details of how this changes the "texture" of the code.

I subconciously wrote the three categories above in my personal preference order; error-handling first seems to me like the worst option, because it would make almost all lines of code be dominated by their error handling. I most prefer the first category, although I must admit I've also become accustomed to how Go code is currently written and so I don't feel any particular urgency to change it. (I don't object to changing it on principle, but agree with Ian that if it's going to change at all then it should be a change that is very clearly better, due to the cost of making a large amount of code retroactively non-idiomatic.)

I think that's a helpful summarization @apparentlymart.

As pertains to having the an error handling keyword like abort? on the left-hand side, the reason for it is precisely that it occupies "prime real-estate" so to speak. It's a trade-off -- you are reducing 3-4 lines of code into a single line of code so you are effectively trading 2-3 extra lines for 6 characters at the front of the line. I don't think it would be fair to readers to both compress the code and make it look like regular "happy-path" code.

I think it's fair to assume that most programmers scan code for patterns rather than read code carefully line for line, at least initially.

I'd also like to push back a bit against the notion that errors don't belong on the left-hand side. I think errors that force a function to immediately return are very different from errors that can be handled in any manner.

if err != nil { return ... } is effectively another way of indicating that "anything below these lines of code is invalid if err is not nil." I don't think it's accurate to say you are burying the lead if the error is important enough to invalidate the rest of the code in the function. At that point, it is more important than the happy path which is why we currently spend 3 lines to make sure the error is not nil.

I obviously can't speak to whether or not this constitutes an excellent change, but I will say if there is a construct powerful enough to both check for errors and return from the function, it should not be hidden somewhere programmers aren't accustomed to scanning. It should be obvious that a function could potentially return at that point.

@apparentlymart
there is a 4th option or abandoning the locality of error handling (in terms of line vicinity but still within the bounds of the function). (according to the lines of #32437) which would be my favorite
but in the context of preserving locality your example nr. 2 could be simplified with appropriate support into something like

DoSomething() or return fmt.Errorf("doing something: %w", err)
or
res := DoSomething() or return err

it still gives priority to the happy path and reduces the information overload on error path. I'm not sure if it something like this can be implemented purely as sugar and the compiler then adds the usual if err != nil that at this point is just noise. On those cases that need a different condition (different than is not nill) the current pattern can be used.

Anyway I think that bridging the divide between those who think the happy path should be more readable and those who think that happy path is/should be no different than the error path is almost impossible as the history of countless proposals shows.

In that light I don't agree that every proposal should be seen under the "is this the best possible proposal?" question.
Maybe I'm wrong but I don't see a technical way to solve what is a point of view difference.
So maybe the question is, should go insist on "one true way" of doing error handling or supporting both views by chosing a second augmenting way in addition the current one.

Per #63575 (comment), this is a rather large change in syntax that doesn't quite fit with the rest of the language. Additionally, the emoji voting is not in favor. Marking as likely decline and leaving open for four weeks for additional comments.

I think annotations are very convenient，

func do() error {
  var err error
  @error("some error")
  res , err := foo()

  @error("some error")
  res , err2 := foo2()
}

or unified processing

func do() error {
  @error("some error")
  var err error
  
  res , err = foo() // if err != nil，directly return without executing subsequent code
 
  res , err = foo2()
}

No change in consensus.