title: Why can't I assign type's value to an interface implementing methods with receiver type pointer to that type?
body: <p>I am 2-days old in the world of Golang, and going through the <em>go tour</em>. I couldn't help but notice a peculiarity which I cannot seem to be able to come at terms with a proper reasoning.</p>
  
  <p>This code is running perfectly:</p>
  
  <pre><code>package main
  import (
      "fmt"
      "math"
  )
  type Vertex struct{
      X,Y float64
  }
  type Abser interface{
      Abs() float64
  }
  func (v Vertex) Abs() float64{ //method with value receiver argument
      return math.Sqrt(v.X*v.X+v.Y*v.Y)
  }
  func main(){
      var myVer Vertex = Vertex{3,4}
      var inter Abser
      inter = &amp;myVer //assigning *Vertex type to inter
      fmt.Println(inter.Abs())
  }
  </code></pre>
  
  <p>Meanwhile, the following code shows an error:</p>
  
  <pre><code>package main
  import (
      "fmt"
      "math"
  )
  type Vertex struct{
      X,Y float64
  }
  type Abser interface{
      Abs() float64
  }
  func (v *Vertex) Abs() float64{ //method with pointer receiver argument
      return math.Sqrt(v.X*v.X+v.Y*v.Y)
  }
  func main(){
      var myVer Vertex = Vertex{3,4}
      var inter Abser
      inter = myVer //assigning Vertex type to inter
      fmt.Println(inter.Abs())
  }
  </code></pre>
  
  <p>The error is:</p>
  
  <blockquote>
    <p>interface.go:18: cannot use myVer (type Vertex) as type Abser in assignment:
        Vertex does not implement Abser (Abs method has pointer receiver)</p>
  </blockquote>
  
  <p>Until reaching this section of the tour, I could understand that the creators of Go have let-go of the cumbersome notations like</p>
  
  <blockquote>
    <p>(*v).method1name()</p>
    
    <p>(&amp;v).method2name()</p>
  </blockquote>
  
  <p>So that methods with value receivers can be used with both values and pointers, and vice versa.</p>
  
  <p>Why does the language discriminate between the two (value and pointer) when working with interfaces? Wouldn't it be more convenient if the same reference/dereference principles could apply here?</p>
  
  <p>I hope that I am not missing something too apparent.
  Thanks!</p>