FAQ
For example, for

var s *[]int
var t *string


why s[10], t[2] are not shorthands for (*s)[10] and (*t)[2], respectively?
I cannot think out any confusions here. And if

var s *[]*int


then *s[10] only means *((*s)[10]), still no confusions.

Is there any special reason. Or just an unimplemented feature? Can I
suggest it for the future version?

David

--

Search Discussions

  • Kevin Gillette at Jan 25, 2013 at 5:52 pm
    These are relatively rare operations (in other words, how long since you
    started using Go did you start explicitly using *[]int?)

    There is, however, a precedent for this -- what you describe is implemented
    for array pointers, and is a special case because of commonality of use.

    afaict, pointers to slices really only come up in two cases: when a
    function or method needs to modify the original slice header (including
    reflect-based decoders and read/write methods on named slice types that use
    append), and in attempts to work around implementation-specific performance
    characteristics of non-tiny value receivers.

    In either case, with a non-optimizing compiler, there really shouldn't be
    any reason why the following shouldn't work and shouldn't roughly
    equivalent or faster in speed:

    func (s *IntSlice) Less(i, j int) bool { v := *s; return v[i] < v[j] }

    For clarity, and to reduce the number of dereferences, that is what is
    generally recommended in Go, thus mitigating some more of the need.
    Typically one would just ignore performance differences in applications
    where performance is non-critical (especially since the compiler can be
    fixed -- a patch is in review -- rendering your code potentially slower,
    but certainly much less readable over time). The prime example for
    idiomatically using slice pointer-receivers (which may account for nearly
    all practical use cases), is coupled with append:

    func (s *IntSlice) Append(ints ...int) { *s = append(*s, ints...) }

    That case isn't affected by your proposal.
    On Friday, January 25, 2013 8:39:52 AM UTC-7, David DENG wrote:

    For example, for

    var s *[]int
    var t *string


    why s[10], t[2] are not shorthands for (*s)[10] and (*t)[2],
    respectively? I cannot think out any confusions here. And if

    var s *[]*int


    then *s[10] only means *((*s)[10]), still no confusions.

    Is there any special reason. Or just an unimplemented feature? Can I
    suggest it for the future version?

    David
    --
  • David DENG at Jan 26, 2013 at 11:16 am
    Dereference is kinda cheap in many cases, may be only a change on a cpu
    code.

    In IntSlice<https://github.com/daviddengcn/go-villa/blob/master/intslice.go>implementation, there are so many methods of pointer receiveres:
    Add/Insert/Remove/RemoveRange/Clear. Anytime the length of the slice may
    change, I have to use pointer-receiver. Using an assignment statement to
    make the dereference and assign the value to a variable is both ugly and
    inefficiency. So my proposed shorthands can solve them very well.

    David
    On Saturday, January 26, 2013 1:52:01 AM UTC+8, Kevin Gillette wrote:

    These are relatively rare operations (in other words, how long since you
    started using Go did you start explicitly using *[]int?)

    There is, however, a precedent for this -- what you describe is
    implemented for array pointers, and is a special case because of
    commonality of use.

    afaict, pointers to slices really only come up in two cases: when a
    function or method needs to modify the original slice header (including
    reflect-based decoders and read/write methods on named slice types that use
    append), and in attempts to work around implementation-specific performance
    characteristics of non-tiny value receivers.

    In either case, with a non-optimizing compiler, there really shouldn't be
    any reason why the following shouldn't work and shouldn't roughly
    equivalent or faster in speed:

    func (s *IntSlice) Less(i, j int) bool { v := *s; return v[i] < v[j] }

    For clarity, and to reduce the number of dereferences, that is what is
    generally recommended in Go, thus mitigating some more of the need.
    Typically one would just ignore performance differences in applications
    where performance is non-critical (especially since the compiler can be
    fixed -- a patch is in review -- rendering your code potentially slower,
    but certainly much less readable over time). The prime example for
    idiomatically using slice pointer-receivers (which may account for nearly
    all practical use cases), is coupled with append:

    func (s *IntSlice) Append(ints ...int) { *s = append(*s, ints...) }

    That case isn't affected by your proposal.
    On Friday, January 25, 2013 8:39:52 AM UTC-7, David DENG wrote:

    For example, for

    var s *[]int
    var t *string


    why s[10], t[2] are not shorthands for (*s)[10] and (*t)[2],
    respectively? I cannot think out any confusions here. And if

    var s *[]*int


    then *s[10] only means *((*s)[10]), still no confusions.

    Is there any special reason. Or just an unimplemented feature? Can I
    suggest it for the future version?

    David
  • Jesse McNelis at Jan 26, 2013 at 11:28 am

    On Sat, Jan 26, 2013 at 10:16 PM, David DENG wrote:

    Dereference is kinda cheap in many cases, may be only a change on a cpu
    code.

    In IntSlice<https://github.com/daviddengcn/go-villa/blob/master/intslice.go>implementation, there are so many methods of pointer receiveres:
    Add/Insert/Remove/RemoveRange/Clear. Anytime the length of the slice may
    change, I have to use pointer-receiver. Using an assignment statement to
    make the dereference and assign the value to a variable is both ugly and
    inefficiency. So my proposed shorthands can solve them very well.
    It's far more common for a pointer to a slice or a string (or an interface)
    to be an error by a new go dev than to be intentional. By not
    automatically dereferencing the error is highlighted.

    So it's slightly more annoying for rare code and highlights mistakes in
    more common code.


    --
    =====================
    http://jessta.id.au

    --
  • Jan Mercl at Jan 26, 2013 at 12:15 pm

    On Sat, Jan 26, 2013 at 12:16 PM, David DENG wrote:
    Dereference is kinda cheap in many cases, may be only a change on a cpu
    code.
    A slice is an opaque `struct{arr *T; len, cap int}`. Except when being
    a receiver (where optionally automatic address taking is permitted by
    the specs), slices are anywhere else passed by value only, no
    automatic address taken, even where appropriate. This is mostly
    universal for all value types with the notable exception of arrays.

    -j

    --
  • Kyle Lemons at Jan 25, 2013 at 6:42 pm
    It does for arrays, but not for slices, which are already reference types.

    http://play.golang.org/p/GkkBFBK9-K

    x := [...]int{1,2,3,4,5}
    y := &x
    fmt.Println(y[1:4])

    On Fri, Jan 25, 2013 at 7:39 AM, David DENG wrote:

    For example, for

    var s *[]int
    var t *string


    why s[10], t[2] are not shorthands for (*s)[10] and (*t)[2],
    respectively? I cannot think out any confusions here. And if

    var s *[]*int


    then *s[10] only means *((*s)[10]), still no confusions.

    Is there any special reason. Or just an unimplemented feature? Can I
    suggest it for the future version?

    David

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJan 25, '13 at 3:45p
activeJan 26, '13 at 12:15p
posts6
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase