Difference between := and var for implicit types?

<p>In the following:</p> <pre><code>package main import &#34;fmt&#34; func main() { var v = 42 u := 42 fmt.Printf(&#34;v is of type %T\n&#34;, v) fmt.Printf(&#34;u is of type %T\n&#34;, u) } </code></pre> <p>returns</p> <pre><code>v is of type int u is of type int </code></pre> <p>Both methods for creating variables and implicitly giving them the type of &#34;int&#34; seem to work the same. Is there any functional difference between the two?</p> <p>Also, is there any reason to explicitly declare the type when it can be done implicitly? i.e.</p> <pre><code>var v int = 42 //versus var u = 42 </code></pre> <p>Thanks.</p> <hr/>**评论：**<br/><br/>om0tho: <pre><p>No functional difference. One is just shorter than the other. Most of the time, you probably just want to use <code>:=</code>.</p></pre>Croned: <pre><p>So the general consensus in Go is that you shouldn&#39;t explicitly define the type when initializing unless you don&#39;t want the default type?</p></pre>spunky29a: <pre><p>Pretty much. IIRC, this is why:</p> <p>Imagine you&#39;re declaring and assigning from a function instead of a constant. Later on you decide to change the return type (rename, change to interface). Now since you used type inference, your types are updated automatically and you still get static typing and all the edit-time and compile-time benefits that go with it.</p> <p>Someone who explicitly declared the types has to go chase down compile errors and fix them. Even in internal/private code that can be arduous and potentially error prone.</p> <p>There are certain instances where you may want to be explicit on your types, and that&#39;s fine and can be useful, but use it sparingly or you&#39;ll spend your time chasing around a cascading change with little benefit.</p></pre>driusan: <pre><p>Not explicitly declaring the type makes it easier to refactor. For instance, if you change something from returning an int to a typed int, you don&#39;t need to go chase all the places you called the function to update them. (Realistically you probably still have to update some code, but not as much.)</p></pre>Croned: <pre><p>Okay, thanks.</p></pre>desikuttapan: <pre><p>If you can&#39;t initialize a variable, you declare with var else use :=. Is it the right thought process?</p></pre>andradei: <pre><p>Seems plausible enough.</p></pre>lilgnomeo: <pre><p><a href="https://blog.golang.org/constants" rel="nofollow">https://blog.golang.org/constants</a></p></pre>mrekucci: <pre><p>There are some corner cases, see: <a href="https://groups.google.com/forum/#!topic/golang-nuts/eKXhq5gaJuw" rel="nofollow">https://groups.google.com/forum/#!topic/golang-nuts/eKXhq5gaJuw</a></p></pre>TheMerovius: <pre><p>Reason to not infer the type: If you don&#39;t want it to be an int. If you need, for example, an <code>int8</code> or something to pass to a function, you need to declare it as such.</p></pre>kala_pela: <pre><p>If you use var instead of :=, it increases readability. </p> <p>If you use := instead of var, it will increase robustness. If you need change type, you don&#39;t need to find out the declaration. Another advantage is, in many cases default new() is not allowed(when the struct type is private), here you have to use :=. </p></pre>