Hacker News Reader

Comment by majewsky | Hacker News Reader

> Except it also has "primitive" types that can't participate, so many of my functions have to take interface{} instead which is pretty much void*.

Can you elaborate? A primitive value can easily implement an interface if you assign it additional meaning through a type:

  # interface Stringer { String() string }
  func foo(value fmt.Stringer) {
    fmt.Println(value.String())
  }

  foo(1.0) # fails: int is missing method String()

  type ValueMeters float64
  func (v ValueMeters) String() string {
    return fmt.Sprintf("%g meters", float64(v))
  }

  foo(ValueMeters(1.0)) # okay, prints "1.0 meters"

View on HN

The specific case I ran into was using a database library. The function that would compose a database query with custom parameters took interface{} as the parameter type instead of sql.Valuer. I thought this was a mistake, but when I asked the library's author, they said they had to make it take interface{} because primitive types cannot implement sql.Valuer.

Nothing in your comment indicates this is not still the case. You can't implement methods on primitive types, can you? That's a shame.

That's correct, and part of the larger notion that you cannot add methods to types from another module. (Primitive types come from the same pseudo-module that declares append, len, etc.)

Think about it. How would you cleanly implement this? If you allow e.g.

  func (x int) String() string { return strconv.Itoa(x) }

Then what does the compiler do when two modules declare that method? You could forbid it, but this will lead to situations where existing application code breaks because a library is updated and the new library version includes a method that was already implemented (possibly differently) by the application.

The other option is to allow implicit casts such as

  func foo(s Stringer) { fmt.Println(s.String()) }

  foo(1) # implicitly casts to ValueMeters to satisfy Stringer interface

But then you run into the same problem. How would you select (forward-compatibly!) the right interface implementation to cast to?

EDIT: The only solution that I can see is to allow function overloads:

  func foo(s Stringer) { ... }
  func foo(x int)      { ... }

Without having thought it through very far, I think that this can be done consistently (precisely because all types are final in Go once the module is cmplete), but it would probably still lead to some surprising behavior.

Actually, I just now see a problem with this:

  func foo(x int)  { ... }
  func foo(x uint) { ... }

  foo(0) # which one to use?

Literals don't have a type in Go until they're used in a place that requires a specific type. To make this example even more interesting, consider this:

  func foo(x int)  uint { ... }
  func foo(x uint) int  { ... }

  fmt.Printf("%t", foo(0)) # prints "uint" or "int", but which?

ValueMeters isn't a primitive type, it's just convertible to one.

    x := 1.0
    y := ValueMeters(1.0)
    x + y // Mismatched types error - ValueMetres and float64

Because Go doesn't believe in operator overloading, there isn't even anything you can do about it. You have to abandon the pretence and explicitly convert the values to the same type.

Go does a little magic with literals in that it will implicitly use explicit conversions on them to satisfy type constraints, so ValueMetres(1) + 1 works, but ValueMetres(1) + float64(1) does not. (Otherwise you end up with annoyances like not being able to add "1" to a float.)

This gets particularly gnarly when interacting with libraries which expect the underlying type you're wrapping:

    x := ValueMetres(math.Sin(float64(x)))

Reply on news.ycombinator.com