Default value in Go's method

Question

Is there a way to specify default value in Go's function? I am trying to find this in the documentation but I can't find anything that specifies that this is even possible.

func SaySomething(i string = "Hello")(string){
...
}

Solution 1

No, the powers that be at Google chose not to support that.

https://groups.google.com/forum/#!topic/golang-nuts/-5MCaivW0qQ

Solution 2

NO,but there are some other options to implement default value. There are some good blog posts on the subject, but here are some specific examples.

Option 1: The caller chooses to use default values

// Both parameters are optional, use empty string for default value
func Concat1(a string, b int) string {
  if a == "" {
    a = "default-a"
  }
  if b == 0 {
    b = 5
  }

  return fmt.Sprintf("%s%d", a, b)
}

Option 2: A single optional parameter at the end

// a is required, b is optional.
// Only the first value in b_optional will be used.
func Concat2(a string, b_optional ...int) string {
  b := 5
  if len(b_optional) > 0 {
    b = b_optional[0]
  }

  return fmt.Sprintf("%s%d", a, b)
}

Option 3: A config struct

// A declarative default value syntax
// Empty values will be replaced with defaults
type Parameters struct {
  A string `default:"default-a"` // this only works with strings
  B string // default is 5
}

func Concat3(prm Parameters) string {
  typ := reflect.TypeOf(prm)

  if prm.A == "" {
    f, _ := typ.FieldByName("A")
    prm.A = f.Tag.Get("default")
  }

  if prm.B == 0 {
    prm.B = 5
  }

  return fmt.Sprintf("%s%d", prm.A, prm.B)
}

Option 4: Full variadic argument parsing (javascript style)

func Concat4(args ...interface{}) string {
  a := "default-a"
  b := 5

  for _, arg := range args {
    switch t := arg.(type) {
      case string:
        a = t
      case int:
        b = t
      default:
        panic("Unknown argument")
    }
  }

  return fmt.Sprintf("%s%d", a, b)
}

Solution 3

No, there is no way to specify defaults. I believer this is done on purpose to enhance readability, at the cost of a little more time (and, hopefully, thought) on the writer's end.

I think the proper approach to having a "default" is to have a new function which supplies that default to the more generic function. Having this, your code becomes clearer on your intent. For example:

func SaySomething(say string) {
    // All the complicated bits involved in saying something
}

func SayHello() {
    SaySomething("Hello")
}

With very little effort, I made a function that does a common thing and reused the generic function. You can see this in many libraries, fmt.Println for example just adds a newline to what fmt.Print would otherwise do. When reading someone's code, however, it is clear what they intend to do by the function they call. With default values, I won't know what is supposed to be happening without also going to the function to reference what the default value actually is.

Comments

[nemo]

Also this discussion with official statement and this related question.

[Rotareti]

What a pain. I wish it was: func Concat1(a string = 'foo', b int = 10) string { like in most other modern languages... It would reduce any of the given examples pretty much to one line of code.

[ProgramCpp]

Do we have an option of writing two different functions and leave it to the caller to be explicit about what they expect.

[Sam Gomena]

I like and agree with this answer but damn do I still wish they at least had an obtuse but idiomatic way of doing it.

[MikeSchinkel]

The "just add another function" argument can result in an explosion of methods required to deal with multiple permutations, requires the burden of deciding on meaningful, discoverable and rememberable names for those methods, and adds burden to learning the packages that use more methods vs. less. #jmtcw

[Vüsal]

@ProgramCpp no, golang doesn't allow function overloading Does the Go language have function/method overloading?

[mukunda]

Well, as someone who has had to untangle mountains of source code 10-20years later to find bugs to support customers, I think additional function names might have some benefit