<p>Is it idiomatic for a constructor to return a pointer to a newly created struct? Or does it depend on the size of the newly constructed struct? Most examples I see return a pointer but I don't know why.</p>
<hr/>**评论：**<br/><br/>Sythe2o0: <pre><p>It depends on the use case. Do you want the methods of the struct to generally modify the struct in place, or do you want the user to need to create or copy to a new struct when they want to make modifications?</p>
<p>Generally, if the struct is rather large, a pointer is preferred for efficiency but most structs won't be large enough for that decision to matter most of the time.</p></pre>jerf: <pre><p>Contra the other posts in this thread as I write this, whether or not the struct needs to be modified by the user is <em>not</em> a determining factor in the decision. <a href="https://play.golang.org/p/QytLRByXNg" rel="nofollow">What a method does is based on the method signature, not what you have</a>; pointer methods can be called on non-pointer structs with no problem.</p>
<p>(You do need to pick either pointer methods or non-pointer methods to implement a given interface, but that's another question.)</p>
<p>The questions around whether you return a struct or not are all much more subtle than that and I typically don't spend a lot of time thinking about it. A direct return involves a copy into the caller, and you probably don't want to do that with big structs very often. Returning a pointer involves less copying. Either way, the caller can convert to what they want on the spot, either by taking the address of the returned value or dereferencing the pointer. Returning a struct directly probably gives the escape analyzer a better clue that this doesn't escape, there may be scenarios where that may make a difference.</p>
<p>Mostly I wouldn't worry too much about this either way until you've got some code that is doing the wrong thing and it's a performance problem.</p></pre>Sythe2o0: <pre><p>I would say that mixing pointer and non-pointer methods is very unintuitive (and will be caught by linters), so you should probably only be using one or the other, and while you can return a struct and have it use the pointer methods, that struct won't satisfy any interfaces the struct's pointer does:</p>
<p><a href="https://play.golang.org/p/Z9bakv8_rx" rel="nofollow">https://play.golang.org/p/Z9bakv8_rx</a></p>
<p>So while its true that the type you return doesn't determine how methods will work, the type does determine what interfaces are satisfied by the result which can cause confusion or forced casting if the method receiver doesn't line up with the constructor return value. I'm in favor of having a 'canonical' type for each struct, either a pointer or not, and having all receivers of that struct use that type and all constructors return that.</p></pre>everdev: <pre><p>Code tends to read a little better with struct pointers because any modifications to the struct pointer are persisted. Without a pointer, you could modify the struct values in one function but forget to replace the original struct with the modified one in the calling function. I can't think of many common use cases where you'd want to modify a copy of a struct and then ignore the modified copy. So, if you want to modify your struct values, easier to use a pointer.</p></pre>md2perpe: <pre><p>If you want to put "methods" on the struct and some methods might modify the content in the struct, then you need a pointer.</p></pre>
