I agree with you on the correct solution - vs. the OP’s request of the GetWrappedXXXX method.
I guess I still don’t understand the “zeroed” concern though. If you adhere to the “don’t mutate values…” then why do the zero copy at all ? The state of the body should still be the state it was passed in as (unless the caller was breaking the aforementioned rule anyway…). Having “blessed types” is not a good design IMO - better to just declare the required interfaces and use those - especially when the object being provided as a parameter is already an interface… just seems lazy… (and long-term error prone). > On Feb 7, 2019, at 3:05 PM, Dan Kortschak <d...@kortschak.io> wrote: > > Their is an assumption in the code that users don't mutate values under > the feet of routines that have been called. The copy does not protect > against that and is not designed for that purpose; it is there to make > the GetBody function return a zeroed copy of the body (for some > definition of zeroed - zero is the state that was handed in to the > NewRequest call). If the behaviour of the copy here is broken, any Go > code that causes a slice, map or pointer to be retained is broken since > the user can mutate the backing data after the call has done work on > it. This becomes a philosophical point. > > There is a simple work around (not as simple as having NewRequest Just > Do The Right Thing™, but reasonable) that does not require reflect and > puts the control in the users' hands. Since the ContentLength and > GetBody fields are exported, they can be set after the return of > NewRequest in the same way that NewRequest does for the blessed types, > but with the users' knowledge of internal behaviours of their types. > > An example of this is here https://bitbucket.org/ausocean/iot/pull-requ > ests/42 > > On Thu, 2019-02-07 at 14:55 -0600, robert engels wrote: >> I see the documented use of the types in NewRequest - you are correct >> - I was wrong. >> >> But, it could of easily also declared that if the provided Reader is >> also a Lener, it uses it to determine the content length. Why have >> this behavior for Closer and not for Lener? Then you don’t need the >> type switch. You say, well the copy... >> >> The current code with the copy is broken - the caller could continue >> to modify the contents of the bytes.Buffer and things would not work >> as expected since the backing array of the slice is shared - so how >> is the copy helping ? The length will remain the same, but the data >> represented could be corrupted. >> >> The correct solution is to declare that NewRequest takes an interface >> Content, that has both Reader and ContentLength methods, where >> ContentLength() can return -1 if the content length is indeterminate. >> Then declare simple facades for Content from bytes.Buffer, a string, >> etc. And also declare that continued use of the Content after >> NewRequest is undefined. And if you wanted to retain the simplicity, >> just declare it uses ContentLength like it uses Closer. >> >> I am all for the simplicity of Go, but “solutions" like NewRequest >> are not the way modern software should be developed. Casting an >> interface to a concrete type is a sign of code that needs design >> work. Having to read the doc in addition to the method signature is >> also a sign the interface needs work (primarily since changes to the >> doc can/will/might change behavior but it avoids compile time type >> checking = brittle code with obscure bugs). >> >> >>> >>> On Feb 7, 2019, at 1:56 PM, Dan Kortschak <d...@kortschak.io> wrote: >>> >>> I didn't mention the word internal, nor did I imply it; with >>> documentation stating that it would be used, it is clearly *not* >>> internal. >>> >>> If you look at the code in question, you can see a probable reason >>> why >>> a Lener interface is not used; for each of the blessed types, a >>> concrete copy of the pointed-to-value is made to allow GetBody to >>> return it. This cannot be done with an interface value without the >>> use >>> of reflect. >>> >>> Please show me a Len method in the standard library that does not >>> return the number of available-to-access elements in a collection. >>> >>> >>> On Thu, 2019-02-07 at 13:27 -0600, robert engels wrote: >>>> >>>> I am not following. You stated that the usage of Len was internal >>>> and >>>> a type switch on known concrete types, so how is related to how >>>> the >>>> OP was attempting to have things work? >>>> >>>> There is no “generally accepted use of Len()”, otherwise it would >>>> not >>>> need to perform a type switch on known concrete types - it would >>>> cast >>>> to an interface declaring Len(), and use the interface, and then >>>> it >>>> would work with any type. >>>> >>>>> >>>>> >>>>> On Feb 7, 2019, at 1:07 PM, Dan Kortschak <d...@kortschak.io> >>>>> wrote: >>>>> >>>>> Yeah, I'm not agreeing with you. >>>>> >>>>> On Thu, 2019-02-07 at 07:07 -0600, Robert Engels wrote: >>>>>> >>>>>> >>>>>> You are agreeing with me. A type switch on concrete types >>>>>> (that >>>>>> you >>>>>> control) is far different than using an available Len() >>>>>> method >>>>>> and >>>>>> assuming the same semantics. >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Feb 7, 2019, at 1:05 AM, Dan Kortschak <d...@kortschak.io >>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Addressing the first sentence, it was a direct answer to a >>>>>>> comment >>>>>>> you >>>>>>> made: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> But is it really? If you read the description for Len() >>>>>>>> on >>>>>>>> bytes.Buffer it is the length of unread portion. But that >>>>>>>> doesn’t >>>>>>>> mean the buffer isn’t just a portion of the entire body - >>>>>>>> it >>>>>>>> can >>>>>>>> be a >>>>>>>> chunk which is continually reloaded. >>>>>>> As far as the claim that there is a need to have a Len >>>>>>> method >>>>>>> in >>>>>>> io.Reader, have a look at the code in question. It type >>>>>>> asserts >>>>>>> on >>>>>>> three concrete types that are known to the function, all >>>>>>> three >>>>>>> have >>>>>>> a >>>>>>> Len method and this is used to obtain the known length. All >>>>>>> other >>>>>>> io.Readers are considered to have an unknown length. >>>>>>> >>>>>>> Whether it's wrong to use Len depends on whether there is a >>>>>>> generally >>>>>>> accepted and consistent set of semantics to Len() int. >>>>>>> There >>>>>>> is. >>>>>>> This >>>>>>> is strengthened if the use of an existing Len method is >>>>>>> noted >>>>>>> in >>>>>>> the >>>>>>> docs. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, 2019-02-06 at 15:50 -0600, robert engels wrote: >>>>>>>> I am not sure what that has to do with the discussion. My >>>>>>>> point >>>>>>>> was >>>>>>>> that for it to be applicable here, it needs to be defined >>>>>>>> as >>>>>>>> part >>>>>>>> of >>>>>>>> io.Reader, since that is what Body is declared as. It is >>>>>>>> not, >>>>>>>> so >>>>>>>> using in the manner outlined is not correct IMO. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 6, 2019, at 3:37 PM, Dan Kortschak <dan@kortscha >>>>>>>>> k.io >>>>>>>>>> >>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> The generalised semantics of Len are that it returns >>>>>>>>> the >>>>>>>>> number >>>>>>>>> of >>>>>>>>> available elements in the collection, being a cognate >>>>>>>>> of >>>>>>>>> the >>>>>>>>> len >>>>>>>>> built- >>>>>>>>> in. This means that as you consume elements from a >>>>>>>>> buffer, >>>>>>>>> the >>>>>>>>> Len >>>>>>>>> value reduces. This is directly equivalent to >>>>>>>>> >>>>>>>>> for len(buf) != 0 { >>>>>>>>> println(buf[0]) >>>>>>>>> buf = buf[1:] >>>>>>>>> } >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, 2019-02-06 at 08:56 -0600, Robert Engels >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> But is it really? If you read the description for >>>>>>>>>> Len() >>>>>>>>>> on >>>>>>>>>> bytes.Buffer it is the length of unread portion. But >>>>>>>>>> that >>>>>>>>>> doesn’t >>>>>>>>>> mean the buffer isn’t just a portion of the entire >>>>>>>>>> body - >>>>>>>>>> it >>>>>>>>>> can >>>>>>>>>> be a >>>>>>>>>> chunk which is continually reloaded. >>>>>>>>>> >>>>>>>>>> This is the danger in using private APIs publically >>>>>>>>>> based >>>>>>>>>> upon >>>>>>>>>> the >>>>>>>>>> existence of a method - it leads to very brittle code >>>>>>>>>> - >>>>>>>>>> and >>>>>>>>>> there >>>>>>>>>> are >>>>>>>>>> almost certainly better ways to design it to avoid >>>>>>>>>> these >>>>>>>>>> issues. >>>>>>>>>> If >>>>>>>>>> the core api is not expressive enough then it will be >>>>>>>>>> more >>>>>>>>>> difficult. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Feb 6, 2019, at 8:30 AM, Burak Serdar <bserdar@i >>>>>>>>>>> eee. >>>>>>>>>>> org> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Feb 6, 2019 at 5:15 AM Robert Engels >>>>>>>>>>>> <rengels >>>>>>>>>>>> @ix. >>>>>>>>>>>> netc >>>>>>>>>>>> om.c >>>>>>>>>>>> om> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I see now, but if that can be the case, shouldn’t >>>>>>>>>>>> the >>>>>>>>>>>> Body be >>>>>>>>>>>> documented that the Reader may be a >>>>>>>>>>>> ReaderWithLen, >>>>>>>>>>>> and >>>>>>>>>>>> the >>>>>>>>>>>> consumer is free to type check/cast? If not, you >>>>>>>>>>>> are >>>>>>>>>>>> using >>>>>>>>>>>> internal details that you should not be. >>>>>>>>>>> Yes, the documentation should say if the reader has >>>>>>>>>>> a >>>>>>>>>>> Len() >>>>>>>>>>> method >>>>>>>>>>> it >>>>>>>>>>> would be used to set the ContentLength. Len is no >>>>>>>>>>> longer an >>>>>>>>>>> internal >>>>>>>>>>> detail then. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is a problem with Go in general. Because the >>>>>>>>>>>> returned >>>>>>>>>>>> object >>>>>>>>>>>> “implements” some interface because it happens to >>>>>>>>>>>> have >>>>>>>>>>>> the >>>>>>>>>>>> required method, doesn’t mean it was designed to >>>>>>>>>>>> be >>>>>>>>>>>> used >>>>>>>>>>>> that >>>>>>>>>>>> way, or that it has the required semantics - >>>>>>>>>>>> unless >>>>>>>>>>>> documented to >>>>>>>>>>>> have them. >>>>>>>>>>> I agree with you there. Len() is straight forward, >>>>>>>>>>> but >>>>>>>>>>> in >>>>>>>>>>> general >>>>>>>>>>> just >>>>>>>>>>> because a function is named something doesn't mean >>>>>>>>>>> it'll do >>>>>>>>>>> the >>>>>>>>>>> same >>>>>>>>>>> thing for all implementations. On the other end of >>>>>>>>>>> the >>>>>>>>>>> spectrum >>>>>>>>>>> is >>>>>>>>>>> Java-like interfaces where you want explicit >>>>>>>>>>> inheritance of >>>>>>>>>>> a >>>>>>>>>>> specific >>>>>>>>>>> interface. I don't know if there's anything in >>>>>>>>>>> between, >>>>>>>>>>> but >>>>>>>>>>> I >>>>>>>>>>> like >>>>>>>>>>> Go's approach much better. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Feb 6, 2019, at 2:22 AM, Matteo Biagetti >>>>>>>>>>>> <matteo.biagetti@ >>>>>>>>>>>> gmai >>>>>>>>>>>> l.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Make sense, thanks for explanation >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Il giorno mercoledì 6 febbraio 2019 07:28:54 >>>>>>>>>>>> UTC+1, >>>>>>>>>>>> Burak >>>>>>>>>>>> Serdar >>>>>>>>>>>> ha scritto: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Feb 5, 2019 at 8:13 PM robert engels >>>>>>>>>>>>> <ren.. >>>>>>>>>>>>> .@ix >>>>>>>>>>>>> .net >>>>>>>>>>>>> com. >>>>>>>>>>>>> com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> That’s what I was trying to point out. Your >>>>>>>>>>>>>> design is >>>>>>>>>>>>>> not >>>>>>>>>>>>>> correct. The Body is a Reader, not a Buffer - >>>>>>>>>>>>>> the >>>>>>>>>>>>>> length >>>>>>>>>>>>>> of >>>>>>>>>>>>>> the request/body may be indeterminate - that >>>>>>>>>>>>>> is, >>>>>>>>>>>>>> a >>>>>>>>>>>>>> stream. >>>>>>>>>>>>>> Attempting to get the length of an underlying >>>>>>>>>>>>>> buffer >>>>>>>>>>>>>> is >>>>>>>>>>>>>> not >>>>>>>>>>>>>> only probably not possible, but not correct >>>>>>>>>>>>>> in >>>>>>>>>>>>>> many >>>>>>>>>>>>>> situations. >>>>>>>>>>>>> The length of the body *may* be indeterminate, >>>>>>>>>>>>> and >>>>>>>>>>>>> if >>>>>>>>>>>>> that's >>>>>>>>>>>>> the case, >>>>>>>>>>>>> the underlying Reader will not have a Len >>>>>>>>>>>>> method. >>>>>>>>>>>>> The >>>>>>>>>>>>> design is >>>>>>>>>>>>> to >>>>>>>>>>>>> handle the case where the underlying Reader is >>>>>>>>>>>>> a >>>>>>>>>>>>> Buffer >>>>>>>>>>>>> with a >>>>>>>>>>>>> Len >>>>>>>>>>>>> method. If the Reader has Len, then the >>>>>>>>>>>>> NopCloser >>>>>>>>>>>>> derived >>>>>>>>>>>>> from >>>>>>>>>>>>> that >>>>>>>>>>>>> will also have a Len, and NewRequest can set >>>>>>>>>>>>> the >>>>>>>>>>>>> content >>>>>>>>>>>>> length. If >>>>>>>>>>>>> the Reader does not have Len, then the content >>>>>>>>>>>>> length >>>>>>>>>>>>> is >>>>>>>>>>>>> unknown. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is a reason the Body is a ReaderCloser >>>>>>>>>>>>>> and >>>>>>>>>>>>>> not >>>>>>>>>>>>>> a >>>>>>>>>>>>>> buffer. It is part of the http specification. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 5, 2019, at 9:00 PM, Burak Serdar >>>>>>>>>>>>>> <bse...@ >>>>>>>>>>>>>> ieee >>>>>>>>>>>>>> .org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Feb 5, 2019 at 7:00 PM Robert Engels >>>>>>>>>>>>>> <ren...@ >>>>>>>>>>>>>> ix.n >>>>>>>>>>>>>> etco >>>>>>>>>>>>>> m.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Shouldn’t you just be taking the content >>>>>>>>>>>>>> length >>>>>>>>>>>>>> from >>>>>>>>>>>>>> the >>>>>>>>>>>>>> header if forwarding the same body. There is >>>>>>>>>>>>>> no >>>>>>>>>>>>>> need >>>>>>>>>>>>>> for >>>>>>>>>>>>>> the >>>>>>>>>>>>>> length of the body. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> True. What I was suggesting is a fix for the >>>>>>>>>>>>>> general >>>>>>>>>>>>>> case. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Feb 5, 2019, at 6:53 PM, Burak Serdar >>>>>>>>>>>>>> <bse...@ >>>>>>>>>>>>>> ieee >>>>>>>>>>>>>> .org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Feb 5, 2019 at 5:18 PM Dan Kortschak >>>>>>>>>>>>>> <d.. >>>>>>>>>>>>>> .@ko >>>>>>>>>>>>>> rtsc >>>>>>>>>>>>>> hak. >>>>>>>>>>>>>> io> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Personally, I think this is a bug in the >>>>>>>>>>>>>> behaviour of >>>>>>>>>>>>>> NewRequest. See h >>>>>>>>>>>>>> ttps://github.com/golang/go/issues/18117 for >>>>>>>>>>>>>> some >>>>>>>>>>>>>> additional >>>>>>>>>>>>>> context. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Agreed. One solution could be to have: >>>>>>>>>>>>>> >>>>>>>>>>>>>> type HasLen interface { >>>>>>>>>>>>>> int Len() >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then have NopCloser return a nopCloser with >>>>>>>>>>>>>> len >>>>>>>>>>>>>> if >>>>>>>>>>>>>> the >>>>>>>>>>>>>> underlying >>>>>>>>>>>>>> implementation has len, with the obvious >>>>>>>>>>>>>> changes >>>>>>>>>>>>>> to >>>>>>>>>>>>>> NewRequest.Ugly, >>>>>>>>>>>>>> but can be done without API changes. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, 2019-02-05 at 05:18 -0800, matteo.... >>>>>>>>>>>>>> @gma >>>>>>>>>>>>>> il.c >>>>>>>>>>>>>> om >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> I've the following situation: >>>>>>>>>>>>>> I proxy a request to another server and when >>>>>>>>>>>>>> I >>>>>>>>>>>>>> made a >>>>>>>>>>>>>> POST >>>>>>>>>>>>>> and create >>>>>>>>>>>>>> a new >>>>>>>>>>>>>> request, the contentLength is zero: >>>>>>>>>>>>>> >>>>>>>>>>>>>> req2, _ := http.NewRequest(req.Method, >>>>>>>>>>>>>> newApiUrl >>>>>>>>>>>>>> , >>>>>>>>>>>>>> req.Body) >>>>>>>>>>>>>> fmt.Println("New request from body:", >>>>>>>>>>>>>> req2.ContentLength) // >>>>>>>>>>>>>> print 0 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Checking in the source code of the NewRequest >>>>>>>>>>>>>> func >>>>>>>>>>>>>> Body >>>>>>>>>>>>>> don't >>>>>>>>>>>>>> respect >>>>>>>>>>>>>> some >>>>>>>>>>>>>> interface and populate the ContentLength >>>>>>>>>>>>>> field. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Could be a bug? Which could be a valid >>>>>>>>>>>>>> approach >>>>>>>>>>>>>> in >>>>>>>>>>>>>> order >>>>>>>>>>>>>> to >>>>>>>>>>>>>> create a >>>>>>>>>>>>>> new >>>>>>>>>>>>>> request from an existing one and correct set >>>>>>>>>>>>>> the >>>>>>>>>>>>>> Body >>>>>>>>>>>>>> length? >>>>>>>>>>>>>> >>>>>>>>>>>>>> A working example here: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://play.golang.org/p/SvCDLj0NrXb >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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...@googlegro >>>>>>>>>>>>>> ups. >>>>>>>>>>>>>> com. >>>>>>>>>>>>>> For more options, visit https://groups.google >>>>>>>>>>>>>> .com >>>>>>>>>>>>>> /d/o >>>>>>>>>>>>>> ptou >>>>>>>>>>>>>> t. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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...@googlegro >>>>>>>>>>>>>> ups. >>>>>>>>>>>>>> com. >>>>>>>>>>>>>> For more options, visit https://groups.google >>>>>>>>>>>>>> .com >>>>>>>>>>>>>> /d/o >>>>>>>>>>>>>> ptou >>>>>>>>>>>>>> t. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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...@googlegro >>>>>>>>>>>>>> ups. >>>>>>>>>>>>>> com. >>>>>>>>>>>>>> For more options, visit https://groups.google >>>>>>>>>>>>>> .com >>>>>>>>>>>>>> /d/o >>>>>>>>>>>>>> ptou >>>>>>>>>>>>>> t. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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...@googlegro >>>>>>>>>>>>>> ups. >>>>>>>>>>>>>> com. >>>>>>>>>>>>>> For more options, visit https://groups.google >>>>>>>>>>>>>> .com >>>>>>>>>>>>>> /d/o >>>>>>>>>>>>>> ptou >>>>>>>>>>>>>> t. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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@googlegr >>>>>>>>>>>> oups >>>>>>>>>>>> .com >>>>>>>>>>>> . >>>>>>>>>>>> For more options, visit https://groups.google.com >>>>>>>>>>>> /d/o >>>>>>>>>>>> ptou >>>>>>>>>>>> t. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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@googlegr >>>>>>>>>>>> oups >>>>>>>>>>>> .com >>>>>>>>>>>> . >>>>>>>>>>>> For more options, visit https://groups.google.com >>>>>>>>>>>> /d/o >>>>>>>>>>>> ptou >>>>>>>>>>>> t. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
