Fair enough. Thanks for the explanation. It also seems to imply that the idiomatic way is to have multiple functions as opposed to abusing variadic args, which answers the OP's question.
On Saturday, July 8, 2017 at 2:42:30 PM UTC-7, Rob 'Commander' Pike wrote: > > From https://talks.golang.org/2012/splash.article: > > *One feature missing from Go is that it does not support default function > arguments. This was a deliberate simplification. Experience tells us that > defaulted arguments make it too easy to patch over API design flaws by > adding more arguments, resulting in too many arguments with interactions > that are difficult to disentangle or even understand. The lack of default > arguments requires more functions or methods to be defined, as one function > cannot hold the entire interface, but that leads to a clearer API that is > easier to understand. Those functions all need separate names, too, which > makes it clear which combinations exist, as well as encouraging more > thought about naming, a critical aspect of clarity and readability.* > > -rob > > > On Sun, Jul 9, 2017 at 3:14 AM, Dragos Harabor <dh...@harabor.com > <javascript:>> wrote: > >> This is where having defaults for function arguments would make for a >> nicer API, like python and other langs. Go 2. Maybe. >> >> I agree that the variadic version is not great for a public API, though I >> do abuse it in test helpers because it's convenient. >> >> On Friday, July 7, 2017 at 10:42:25 PM UTC-7, Dave Cheney wrote: >>> >>> 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 <da...@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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
