Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It surprised me how go's interfaces have non-trivial limitations. What lately bit me is illustrated in the following snippet: the call to doSomething() is just not possible in Go:

  package main

  import "fmt"

  type S struct {
        i int
  }

  func (s *S) foo() {
        s.i++
        fmt.Println(s.i)
  }

  type Sarr []S

  type I interface {
        foo()
  }

  func doSomething(arg []I) {
        arg[0].foo()
  }

  func main() {
        arr := Sarr{S{i: 1}, S{i: 2}, S{i: 3}}
        arr[1].foo()

        doSomething(arr)
  }
I understand why the current implementation of Go doesn't work that way, and that the meta-reason for this not being implemented is the "we don't want generics" attitude, since it would effectively require 2 different compilations of doSomething(), one which accepts a slice of interfaces, which are a (pointer,type) tuple, and one which accepts an slice of this specific struct which happens to actually implement the I interface, and that's a taboo, but come on... it just weakens the idea of interfaces. It could have been done as a compile-time work-around which constructs the slice-of-interfaces argument on-the-fly before calling the function - it wouldn't have been the only magical thing in Go.


>It could have been done as a compile-time work-around which constructs the slice-of-interfaces argument on-the-fly before calling the function - it wouldn't have been the only magical thing in Go.

Is there a language that works the way you describe ?


Not quite, but I believe Nim works similarly. But it also has generics, and it’s function dispatch resolution is neat, so it’s not quite apples-to-apples


The reason this doesn’t work is because conversions of this nature may require allocations, and like C++, Go doesn’t want to hide costly operations from the author.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: