Comment 1:

Sorry, forgot to complete the Issue title, and I can't change it.
It would be: "sync: Export WaitGroup.counter and WaitGroup.waiters"

Comment 2:

I don't think we're likely to make this API more complex.  I don't see any way to use
counter and waiters that is not subject to race conditions, other than simply printing
them out.  And for that you can maintain your own counts.

Labels changed: added repo-main.

Comment 3:

I don't get it why this will make this API more complex.
To have my own counter I'll need to duplicate something that is already inside the API,
but not exported. Things can become a bit "duplicated":
http://play.golang.org/p/sr3MCVk5Rw

Comment 4:

Any additions to an API make it more complex, as a matter of definition.
The Go 1 guarantee (http://golang.org/doc/go1compat) means that if we add exported
fields to WaitGroup, we are promising to maintain those fields forever.  That would
limit our ability to change WaitGroup in the future.

Comment 5:

Indeed, just last week I was thinking about replacing waiters with a goroutine list.
Herbert, what do you want to do?

Comment 6:

I would like to:
- instrument/monitor the application
- be able to safely abort every blocked WaitGroup.Wait()
I know these can be achieved through other ways, but looking at Go source I had this
idea to avoid the necessity of having variables to store the same counters.
If you have plans to rewrite WaitGroup, please, consider these ideas.
We could have methods instead of just exporting those fields (eg WaitGroup.Counter(),
WaitGroup.Waiters()), so future changes in the implementation could be done without
deprecations in the API.

Comment 7:

WaitGroup.Wait does not return an error, so I am not sure how it can be safely aborted
The caller won't be able to understand whether it's aborted or not
WaitGroup is intended to simple cases, for more complex cases (which there are much much
more than just the 2 you described), there are channels/select, or mutexes/condvars and
atomic operations.
E.g. here how you can have abortable wait with select:
func waitWithTimeout(c chan struct{}, n int, d time.Duration) bool {
  t := time.After(d)
  for i := 0; i < n; i++ {
    select {
    case <-c:
    case <-t:
      return false
    }
  }
  return true
}

Comment 8:

Ok, then. 
Sorry for bringing this as an issue before discussing it on go-nuts.
Thank you for your time.

Comment 9:

Status changed to WontFix.