proposal: spec: define _ on rhs as zero value

[dans-stuff]

Currently, _ only has behaviour on the LHS.

I would like to propose giving it meaning on the RHS as meaning "zero value". This has two main areas of effect.

First, when returning from a function with multiple return values, you can omit the zero-value allocation. For example,

func GetString() (string, error) { return _, errors.New("nostring") }

Understandably you can use named returns as well, but that is less than ideal if you use the named return value as a "scratch space" before deciding to return zero anyway. For example, when building some struct, such as a Request, you might use a named return to build it and, later in the function, come across an error which invalidates your scratch space, in which case you would want to return a zero-value instead of a half-initialized struct with some garbage inside.

Second, when you want to reset a struct, such as when using a pool, you could use _ to restore it to a zero-value.

func Pool() func() (User, func()) {
	var pool User
	// in reality, use some pooling mechanics
	return func() (u User, reset func()) {
		return pool, func() {
			// zero out and return this copy to the pool
			pool = _
		}
	}
}

nil would remain the correct way to create the zero-value for reference types.

[bradfitz]

This has been proposed and rejected in the past. I'll try to dig up references.

[bradfitz]

Previously:

@nigeltao's in Jan 2012:
https://groups.google.com/forum/#!msg/golang-dev/iAysKGpniLw/qSbtBUx4-sMJ

(@robpike had said "not now")

@derekchiang in Sep 2013:
https://groups.google.com/forum/#!topic/golang-nuts/kBOnfs3a2tU

@kr in Aug 2010:
https://groups.google.com/d/msg/golang-nuts/VXWNJQFCgts/V2ED_W_tCdEJ

[dsnet]

As a consideration, a different language proprosal (#12854) for stronger type elliding may solve what this proposal is trying to do.

Returning the zero value is only painful for structs. The proposal in #12854 would allow the following:

func MyFunc() (otherpkg.ReallyLongStructName, error) {
	return {}, errors.New("not implemented")
}

[dans-stuff]

dsnet, the {} syntax would more clearly differentiate it's use from nil, plus it builds on existing syntax. I love it, a definitely improvement over _.

[randall77]

Returning the zero value is only painful for structs, slices, and maps

nil is a fine zero value for slices and maps. "" is fine for strings. 0 is fine for numbers. I think structs are the only types that would benefit from a more succinct zero.
Doesn't seem worth it to me. (But if #12854 solved this as a side effect, that would be ok.)

[ianlancetaylor]

It's interesting to note that we can get an expression for the zero value for any type by using reflect.Zero, but there is no corresponding language construct. The closest we can come in the language is to declare a variable of that type.

[robpike]

That is interesting, but changing _ to address that disparity feels wrong to me. Not a very scientific comment, I admit.

[dans-stuff]

I agree, the {} syntax blows overloading _ out of the water in hindsight.

[rogpeppe]

Personally, I'm an advocate for a new "zero" identifier, similar to nil
apart from that it can be used for values of any type, not just pointer types.

[robpike]

Then propose it, @rogpeppe.

[nigeltao]

FWIW, I'm still in favor of the original proposal: a new "zero" identifier, just spelled "_".

Just recently, in https://go-review.googlesource.com/c/38280/2/font/sfnt/sfnt.go#867 I changed e.g.
return nil, ErrNotFound
to
return nil, 0, 0, ErrNotFound
and having to distinguish "nil" versus "0" here seems like unnecessary, and unimportant, detail. I'd rather write:
return _, _, _, ErrNotFound

Off-topic, but while I think of it, alternative sugar for this particular line could be
return ... ErrNotFound
but I'm not sure if even I like that idea.

[rogpeppe]

Then propose it, @rogpeppe.

I'm not sure another proposal would add much value. Perhaps the title of this one could be changed to something like "Proposal: define an identifier that means the zero value for all types", because there are a number of possibilities for spelling, but the gist is the same regardless.

@nigeltao I agree that can be a pain, particularly when there are many return statements and even more so when returning struct types by value. I've come to like this idiom:

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
	fail := func(err error) ([]byte, int, int, error) {
		return nil, 0, 0, err
	}
	xx := int(x)
	if f.NumGlyphs() <= xx {
		return fail(ErrNotFound)
	}
	i := f.cached.locations[xx+0]
	j := f.cached.locations[xx+1]
	if j < i {
		return fail(errInvalidGlyphDataLength)
	}
	if j-i > maxGlyphDataLength {
		return fail(errUnsupportedGlyphDataLength)
	}
	buf, err = b.view(&f.src, int(i), int(j-i))
	return buf, i, j - i, err
}

That idiom also makes it easier to add and remove return values.
Currently the compiler's not clever enough to make it cost-free,
(well, it wasn't the last time I checked) but I don't see why it shouldn't.