ergonomics: `Set*` methods for Optional fields should accept the underlying type instead of Opt

[jaqx0r]

Description

It is a weird ergonomic to have an optional field and be required to construct the OptX to pass to SetX, instead of the generated API doing this itself.

The semantics of Set imply that the field becomes no longer unknown, but has a value.

E.g.

optx := OptString{Value: "string", Set: true}
s.SetX(optx)

versus

s.SetX("string")

[zguydev]

It is expected for SetX method to accept generated types like OptString, as that keeps the setter consistent with the actual schema type. More importantly, this gives you nice helper methods, which you can use to control the field. ogen also generates helper functions aswell, like constructors.

E.g. in your example you could use a NewOptString constructor:

s := gen.SomeResponse{}
s.SetField1(gen.NewOptString("something"))

Another way is to call the field's method SetTo, which doesn't use generated types and for this example accepts string:

s.Field1.SetTo("something")

There are plenty of other useful methods, e.g. to reset a field or check if the field is set, so it's highly ergonomic for all needs

[jaqx0r]

OK thanks, I wasn't aware of the SetTo interface!

My problem stems from:

I have several API specs, each generating their own service handlers with ogen.
The Error schema is shared between them, and I want a common implementation of NewError.
The common implementation uses generics to cope with the different instantiations of the same schema in each API service handler.
OptString and friends cannot be used directly in the package because that would cause a cyclic dependency, and the generic's type parameter interface is already large (because the resource setter methods take pointer receivers but return values, but that's another story)

I think SetTo solves my issue though, thanks.

I wonder if there's a reference for the generated API that could be inlcuded in the manual? Currently the godoc describes the internals of ogen itself, but there isn't a handy guide for the generated code (somethign like what Protobuf does fo https://protobuf.dev/reference/go/go-generated-opaque/) (My current workaround is using gopls and jump-to-definition :)