[jflakjwoasdlf]

> tuple[User | None, Exception | None]

tuple[User, None] | tuple[None, Exception]

[goodoldneon]

That type won't help if you're unpacking like `user, err = get_user(user_id)`. Both values will be nullable and the type-checker won't understand that `user` is not None if `err` is None

[progbits]

Yup, don't allow nonsensical states (User+Exception or None+None) to even exist.

The original is more like Go approach which is a big flaw with the language.

[goodoldneon]

Go can be `tuple[User | None, Exception | None]` or `tuple[User, Exception | None]`, depending on whether you're returning a pointer. But yea, Go's approach has its warts. Like if you aren't returning a pointer then you need to return the zero value (e.g. `User{}`) even when returning an error

[progbits]

Yeah but pointer + nil also have issues: https://go.dev/doc/faq#nil_error

I've also seen APIs that allow returning both error and a value ("something went wrong, but here is a fallback or something") which are of course extremely confusing given the usual style.

[goodoldneon]

Oh I agree, I've run into too many nil pointer panics. I wish Go had a first-class way of expressing optionality, rather than using pointers