Proposal to return nil pointers instead of structs on request error

[anniel-stripe]

Is your feature request related to a problem? Please describe.

This feature request is to track community interest in stripe-go API calls returning a nil pointer when the error is not nil. The current behavior in stripe-go when the API call errors is to return both an error and a pointer to a struct with empty / zero value fields.

We've recently been informed that stripe-go does not follow the typical Go convention of returning the zero value (nil in the case of pointers) when an API call function returns a non-nil error value. This convention is not officially documented anywhere as far as we know, but is generally followed (see this related StackOverflow post).

Please feel free to upvote or comment if you would like this feature in stripe-go (or comment with arguments against making this change).

Describe the solution you'd like

In the following function call to create a new payment intent given bad params which raise an error

pi, err := paymentintent.New(badParams) // errors

Old behavior: pi is a pointer to a struct with empty fields on error
New behavior: pi is nil on error

Describe alternatives you've considered

No response

Additional context

Related links:
Is it conventional to return both value and error from function at the same time SO post
Stripe docs for error handling

[epelc]

This would be much more inline with typical go apis.

[Thiht]

Some APIs definitely do that but I disagree that it's more idiomatic or more of a convention than the opposite. I'd even say Go usually discourages using pointers when they're not needed.

Preferences apart, a disadvantage of returning pointer is that it's nullable. This means that to be thorough I have to check that the value is not nil in addition to checking that the error is nil. Because after all, returning nil, nil can be valid, it depends, and now it gets encoded in all the signatures that it's a possibility. It also means that when it's not nil, I may need to dereference it to manipulate it (since I'll definitely use non-pointers in my code), hence I'll need a nil-check. In normal circumstances (ie. not for low level optimization) I would not return a pointer if nil is not a value that makes sense.

All in all, I believe it's a huge breaking change for no good reason, especially given the fact than no solution is more idiomatic than the other, it's just a case of "pick one and stick to it". So I'd recommend to stick to the current for the sake of not introducing a breaking change for very little (if any) gain.