Sorting out Go's 'for ... = range ..' and when it copies things

17

Sorting out Go's 'for ... = range ..' and when it copies things go utcc.utoronto.ca
via calvin 3 years ago | archive
Archive.org Archive.today Ghostarchive
| 6 comments

6

1. 4
  
  olegkovalov 3 years ago | link
  
  BTW, for the such and similar situations go-critic has checks rangeValCopy and rangeExprCopy
  
  See docs: https://go-critic.github.io/overview
  
  Repo: https://github.com/go-critic/go-critic
  1. 1
    
    mperham edited 3 years ago | link
    
    Thanks, I integrated it into my codebase. The default sizeLimit of 512 seems rather large, I would expect to see something like 64.
    
    https://github.com/contribsys/faktory/blob/master/.golangci.yml
    1. 2
      
      olegkovalov 3 years ago | link
      
      go-critic has a support for config per checker, look for @rangeExprCopy.sizeThreshold on the overview page :)
      
      And from what I see there is no mention of go-critic config param (oops), we’ll update docs soon.
      1. 2
        
        mperham 3 years ago | link
        
        Yeah, I dug thru it and config’d golangci-lint. See link above.
    2. 2
      
      quasilyte 3 years ago | link
      
      Just in case if you didn’t know: you can change the default size with -@rangeExprCopy.sizeThreshold parameter.
      
      To get a list of checkers, run: gocritic doc.
      
      To get info about a checker, run: gocritic doc <checkerName>.
      
      So, in case of the rangeExprCopy you do “gocritic doc rangeExprCopy” and it tells what parameters are available.
2. 1
  
  p5v 3 years ago | link
  
  I think this is somewhat standard behavior. In other programming languages, the compiler, or latest, the runtime might try to prevent modifications to a looped-over collection. Go would allow that when using a pointer. Makes sense from a semantic point of view. Treat the ranged-over slice as immutable, unless you use a pointer to it.