Re: [go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-07 Thread Pedro Luis Guzmán Hernández
Thanks all, I'll continue to call it for now, since that's what most engineers on my team would expect in that situation, but I'll happily reconsider if some documentation gets added at some point. El miércoles, 7 de febrero de 2024 a las 0:44:13 UTC+1, Ian Lance Taylor escribió: > On Tue, Fe

Re: [go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-06 Thread Ian Lance Taylor
On Tue, Feb 6, 2024 at 6:29 AM Pedro Luis Guzmán Hernández wrote: > > Thanks Brian. That is an implementation detail though, so relying on it with > no mention in the documentation at all feels unsound. A Close method usually > means you have to defer it right after getting the resource, so I wo

[go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-06 Thread 'Brian Candler' via golang-nuts
Documentation could certainly be improved, since the Part.Close() method has literally no documentation. Whilst it does feel unsound, in practice I don't think the behaviour could be changed now without breaking the Go compatibility guarantee (unle

[go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-06 Thread Pedro Luis Guzmán Hernández
Thanks Brian. That is an implementation detail though, so relying on it with no mention in the documentation at all feels unsound. A Close method usually means you have to defer it right after getting the resource, so I would have expected the docs to be more clarifying on its usage. El martes,

[go-nuts] Re: Do we need to call multipart.Part.Close

2024-02-06 Thread 'Brian Candler' via golang-nuts
https://cs.opensource.google/go/go/+/refs/tags/go1.21.6:src/mime/multipart/multipart.go;l=325 All it does is read all the remainder of the part to io.Discard. So if you're sure you've read each part before moving onto the next one, it looks like you should be good. On Tuesday 6 February 2024 a