Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I don’t see how it breaks anything if it’s opt-in. By default you get the current behavior with zero value initialization if that’s what you want (and in many cases it is). But if you’d rather force an explicit value to be supplied, what’s the harm?



> I don’t see how it breaks anything if it’s opt-in?

Zero values are a fundamental, non-optional, "feature" of Go.

> But if you’d rather force an explicit value to be supplied, what’s the harm?

What happens if you use the function above with your type?

Or reflect.Zero?


If it would only complain on struct literals that are missing the value (and force a nil check before access if the zero value is nil to prevent panics), that would be enough for me. In that case, your Zero function and reflect.Zero can keep working as-is.


Then I fail to see the point, that is trivial to lint, just enable the exhauststruct checker.


I wasn't aware of it—will check it out, thanks.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: