proposal: spec: add zero-inequality operator ?

[bdbyrne]

Proposal Details

Background

The Go community has a wealth of opinions on error handling: some are indifferent, some are annoyed, and some want to watch the world burn (#71203[1]). The goal of this modest proposal[2] is to surface a common middle-ground to see if there's any light to be found.

This is a modern generalization of #32845, and aside from the existing error handling proposals, relates to #64825.

Proposal

A new post-fix operator ? evaluates for inequality with the zero value for comparables. For exposition, the following are equivalent:

// error
if err != nil {...}
if err? {...}

// error (2)
if _, err := f(); err != nil {...}
if _, err := f(); err? {...}

// error (3)
ok := err != nil
ok := err?

// *T
if ptr != nil {...}
if ptr? {...}

// int
if value != 0 {...}
if value? {...}

// bool
if value {...}
if value? {...} // OK, but likely vetted

The benefits include:

• Saves six characters[3][4].
• Arguably easier to type on QWERTY keyboards.
• There's no == zero equivalent, so it make those if-statements stand out more.

Sugar

Behavior can be emulated today with:

func nonzero[T comparable](value T) bool {
	var zero T
	return value != zero
}
// Sugar: 'x?' is rewritten as 'nonzero(x)'.

Unconventional cases that should be vetted:

true?/false?
!value?
value??
&value?  // Compiler error

---

[1] Said 100% in jest.
[2] But seriously.
[3] I don't type the spaces and let gofmt add those - OK, four characters.
[4] My editor auto-completes and I just hit tab - OK, fair enough.

[mateusz834]

A new post-fix operator ? evaluates for inequality with the zero value on comparable types except bool. For exposition, the following are equivalent:

I don't think the except bool serves anybody, also this kind of ? operator should work with all types, not only comparable, see #61372.

[gabyhelp]

Related Issues

• proposal: Go 2: Error Operator #65184 (closed)
• proposal: spec: reduce error handling boilerplate using ? #71203
• proposal: "?" as "!= nil" #32845 (closed)
• proposal: Go 2 : add support for conditional statements #25582 (closed)
• proposal: Go 2: Error-Handling Paradigm with ?err Grammar Sugar #60779 (closed)
• proposal: Go 2: `? :` for returning on function errors #65579 (closed)
• proposal: Go 2: Error handling via conditional assignment operators #59664 (closed)
• proposal: spec: permit using nil with type parameters #62487 (closed)
• proposal: spec: error != nil , add ? #57957 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[jimmyfrasche]

This (extended to all zeroes, maybe a vet check for bools) + #21182 would handle a lot of the most common rough spots around zero values and it would be nice to only have to read

if err? {
  return ..., fmt.Errorf("blah: %w", err)
}

While that simplifies the boilerplate around the common cases of returning an error as-is or reacting to/decorating the error and returning, it's still 3 lines to read even if the important parts are more in focus, so I'm not convinced this is a better idea than something that (somehow) does just those 2 things on the same line.

Checking if something is zero looks a bit busy:!something?

[bdbyrne]

I don't think the except bool serves anybody

You're right, there's no major gotchas and vet can help identify unnecessary usage. I've edited the proposal.

I must admit, with the edits in place, it becomes much more similar to past proposals and so may not be worth rehashing. The only difference would be time, as the community seems more open to introducing a new ? operator but still strongly divided.

[ianlancetaylor]

Thanks, but closing as a dup of #32845.