Optional (or default) function arguments

[gopherbot]

by pierre.gotab:

Summary of mailing list related subjects:
There is no optional arguments in Go. (And no function overloading.)
- So this is difficult to port some APIs in Go
- And difficult to write some code (as strings.Split 3rd arg)

Proposed existent workarounds:
Assume we want a function foo taking two integers with the second optional defaulting to
0.

- function wrapper
func foo2(bar int, baz int) {
    // sthg
}
func foo1(bar int) {
    return foo2(bar, 0)
}

Need to write the same thing 3 times or more... Somewhat against the "everything is
declared exactly once" Go principle.

- varargs
func foo(bar int, optional ...int) {
    var baz int = 0
    if len(optional) > 1 {
        panic("Too much args")
    } else if len(optional) == 1 {
        baz = optional[0]
    }
    // sthg
}

Heavy code, catch "Too much args" at execution time.

- struct
type fooArgs struct { baz int }
func foo(bar int, optional fooArgs) {
    baz := fooArgs.baz
    // sthg
}
// call:
foo(3, fooArgs{42})
foo(3, fooArgs{})

Make the call heavy to write and create a struct each call.

Proposed optional arguments specification:
- With default value
func foo(bar int, baz int = 0) {}
func foo(bar int, baz := 0) {}

- Using the zero value
func foo(bar int, baz? int) {} // baz will default to 0 if not set

- With named parameters
func foo(bar int, baz int = 0, qux int = 0) {}
foo(3, qux:5)

The named parameter with default value approach is close to the struct workaround, and
is really flexible.

[robpike]

Comment 1:

Labels changed: added priority-low, languagechange, removed priority-medium.

Status changed to Thinking.

[rsc]

Comment 2:

Labels changed: added priority-someday.

[robpike]

Comment 3:

Status changed to WorkingAsIntended.

[gopherbot]

Comment 4 by crifan2003:

prefer:
With named parameters
or:
With default value
if go will not tend to support this common and useful feature, I would be very
disappointed ..

[gopherbot]

Comment 5 by pierre.gotab:

Unfortunately, the status WorkingAsIntended seems to say "we do not want this kind of
feature", and one of the reasons why I went away from Go.

[adg]

Comment 6:

Optional arguments are often a crutch for poor API design. You tend to think "Oh well,
we can always add it later as an optional argument." Or (worse) "Just add it as an
optional argument." The result (as demonstrated by many Python programs) is functions
that take many optional arguments whose semantics are hard to discern.
Go has design goals, which are discussed at length in this article:
http://talks.golang.org/2012/splash.article
In reading that article, it should become clear why optional arguments are a no-go for
Go.
If you do not share those goals, then you are probably better off using another
language. Sorry.

[gopherbot]

Comment 7 by pierre.gotab:

I understand the pitfalls of optional arguments. But forbidding them because they allow
poor design is not a solution to me. Because when you really need them (and it happens
quite often) you must use one of the "tricks" I mentioned in my first post.
When you write two or three or more functions that call each other to support every
usecase, you write a lot of stupid code. My proposition is just to let the compiler
write this code for you. This is not bad design, it's just syntactic sugar.
But maybe you are considering it's up to a project like Groovy or CoffeeScript to do
this job for us?
And finally, I found no argument about this in the link you gave to me :(

[rsc]

Comment 8:

The [email protected] mailing list is a better place for discussions.

Labels changed: added restrict-addissuecomment-commit.