v4: consider swapping functional options for struct fields

[mvdan]

I think functional options are an interesting idea, and can be a good fit in certain scenarios, but in practice they're overkill and kinda awkward for APIs like our parser or interpreter.

An Options struct would:

• Be easier to understand and use
• Occupy less space in the API docs
• Make it clear that setting APIs does not run arbitrary code
• Likely be more efficient; functional options need to be "applied" to be read

One disadvantage of functional APIs is readability when zero or few options are used, as ...Option can just be missing or contain one Foo(...) option, whereas a struct must at least be nil or Options{Foo: ...}. Still, that seems like a comparatively small price to pay.

[andreynering]

I actually like functional options for public facing APIs. I would personally keep it, TBH.

That's not a strong opinion, though. And you, as the author, certainly has the last word on this decision.

[mvdan]

I admit that functional options look nice when reading and writing code, and aesthetics are also a factor. But ultimately the downsides seem more numerous, at least in the case of our APIs.