Yeah, that's my concern with creating an API which accepts a variadic number of arguments, but strongly encourages you to present at most one. Relying on documentation for thistriction is frankly, lame. Given the set of options, a second function for the uncommon invocation sounds like a reasonable tradeoff.
On Sat, 8 Jul 2017, 15:34 Sam Whited <s...@samwhited.com> wrote: > On Fri, Jul 7, 2017 at 10:24 PM, Dave Cheney <d...@cheney.net> wrote: > > Iff there is only one possible option and it's only used infrequently, > I'd be inclined to try something like this > > > > // Foo returns a new Bar > > func Foo() Bar > > > > // FooWithQuxx returns a new Bar using the underlying Quxx > > func FooWithQuxx(q Quxx) Bar > > I think this is probably what I'll do; I realized earlier that I can't > articulate a reason that I'm resisting expanding the API footprint > with a second function, but do have concrete reasons why I don't like > the other available options. > > I think maybe the only reason I shy away from adding a function is > that I tend to prefer to communicate intent and behavior using the > type system where possible. This is, incidentally, the same reason I'm > always a tad resistant to making things variadic (although the > functional options pattern doesn't bother me, oddly), if only one > argument will be used since the slice communicates intent to accept > multiple arguments (which is then contradicted by the documentation). > Go's type system is very simple (I sometimes think this is Go's > greatest strength, and other times its greatest weakness), so it can > make it hard to do this though… sometimes you just need another > function, I suppose. > > Thanks for the feedback! > > —Sam > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
