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.
