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?


Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 6 | next ›
Discussion Overview
groupgolang-nuts @
postedJan 25, '13 at 3:45p
activeJan 26, '13 at 12:15p



site design / logo © 2021 Grokbase