In addition to the matter of flexibility that others have mentioned, it's a
matter of style. The tendency to pass pointers to be modified in library
code is prevalent in the C-language family languages that do not specify
automatic memory reclamation semantics, thus in most cases with C, it would
result in a lack of control to have the library allocate, and moreover, is
considered bad engineering to separate the responsibilities for allocation
and deallocation (e.g. it's bad for a library to allocate but require the
application to free). Since Go is garbage collected, the runtime solely has
the responsibility for freeing Go-allocated objects, and therefore it
doesn't matter who allocates, thus it's idiomatic to take the more flexible
approach of allowing library functions to allocate and then return that as
And yes, there are plenty of times when you want to keep track of both the
original slice, and an append to that slice, as separate slice variables,
not caring whether they share the same backing array or not.
On Monday, September 30, 2013 3:51:34 AM UTC-6, Ray Long wrote:
when we append a data to a slice
Code : slice = append(slice, 1, 2 )
It seems not so graceful. can it be something like below?
append( &slice , 1, 2)
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 firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.