FAQ
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 golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at Sep 30, 2013 at 1:20 pm

    On Mon, Sep 30, 2013 at 11:51 AM, 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)
    In the current version both the original slice and the returned slice
    are valid and consistent [ len(src)+1 vs len(src) ] wrt the pre-append
    state, even though they may or may not share the same backing array
    and even though the programmer may chose to overwrite the source slice
    with the result slice. That's a common case, but not necessarily the
    only one.

    The proposal does lose this property. What's the advantage of being
    less flexible?

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Chris dollin at Sep 30, 2013 at 1:31 pm
    On 30 September 2013 10:51, 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)

    It makes it rather less graceful when used in a declaration or as
    an argument in a function call.

    Chris

    --
    Chris "allusive" Dollin

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Kevin Gillette at Sep 30, 2013 at 3:40 pm
    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
    a result.

    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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Sep 30, 2013 at 8:28 pm

    On 9/30/2013 8:40 AM, Kevin Gillette wrote:
    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.
        Painfully true.

        Slices (but not their underlying arrays) in Go are almost immutable.
    That is, slice descriptors are usually replaced by new ones, not
    altered. One of the few exceptions is documented here by Russ Cox:
    "http://research.swtch.com/gorace". Altering a slice in place
    creates a potential race condition that can break Go's memory model
    and provides an entry point for exploits. (That's why Google AppEngine
    and Go Playground limit you to one thread.) Cox suggests that slice
    descriptors that are not on the stack should always be replaced by
    newly allocated ones, rather than being modified in place. That
    could be fixed without changing language semantics.

        Adding a way to explicitly modify a slice descriptor in place would
    make this problem worse. That would build modifiable semantics into
    the language and make it more difficult to fix the security hole Cox
    discovered.

         John Nagle


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Harden at Sep 30, 2013 at 4:03 pm
    You can do something very similar yourself already.

    http://play.golang.org/p/7tDJtEZbqm
    On Monday, September 30, 2013 4:51:34 AM UTC-5, 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 golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 30, '13 at 1:11p
activeSep 30, '13 at 8:28p
posts6
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase