On Friday, 21 April 2017 12:28:25 UTC-4, st ov wrote: > > In general, is it advisable to return pointers to newly constructed > instances when using constructors? > > Would it matter more for types that don't have members of composite types > slice and maps? > So in the following example, https://play.golang.org/p/sWTWkHfZfB > > Bar is made up of mostly strings, so should return a pointer as those > strings could be long. > While Foo is constructed of a slice and map, which are just references. So > the constructor can return Foo as a value with little overhead. > And Qux has both a string and slice, but should return a pointer since the > string can be large. > For interface Baz, returning a value is acceptable as its just a reference > to Foo, Bar and Qux. > > Is that all correct? Or should I just always return a pointer? Any other > advise? >
Let the receiver declarations of the type's methods guide you. If the methods of a type T have T as a receiver, you should generally pass values of type T by copying them, either because the values are immutable (such as a string, int, or perhaps a struct made up of immutable values) or because T is or contains a reference such as a map or slice. But if the type's methods are associated with *T, then you should not copy values of type T because this can violate the aliasing invariants of the type. For example, internally, a bytes.Buffer variable contains a pointer to itself, so copying a value of type bytes.Buffer results in a new buffer that is entangled with the original one. I usually suggest the name NewT for a function that returns a pointer to a variable of type T, but MakeT for a function that returns a value of type T, for consistency with the 'new' and 'make' built-in functions. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
