Re: [go-nuts] Re: new range over int docs?

2024-02-06 Thread Jason E. Aten
On Wed, Feb 7, 2024 at 3:34 AM peterGo wrote: > You are reading a specification dated Version of Aug 2, 2023. The current > specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM > EST. > Link? https://go.dev/ref/spec still gives me the Aug 2, 2023 spec, which is what the

[go-nuts] Re: new range over int docs?

2024-02-06 Thread peterGo
Jason, The Go specification "Length and capacity" section defines the len built-in function. Peter On Tuesday, February 6, 2024 at 11:36:21 PM UTC-5 peterGo wrote: > Jason, > > The Go 1.22 specification, in part, > > For statements with range clause > > A "for" statement with a "range" clause

[go-nuts] Re: new range over int docs?

2024-02-06 Thread peterGo
Jason, The Go 1.22 specification, in part, For statements with range clause A "for" statement with a "range" clause iterates through all entries of an array, slice, string or map, values received on a channel, or integer values from zero to an upper limit [Go 1.22]. For an integer value n,

[go-nuts] Re: new range over int docs?

2024-02-06 Thread peterGo
Jason, The Go Programming Language Specification is reference documentation. It is intended to be read very carefully in its entirety. You are reading a specification dated Version of Aug 2, 2023. The current specification for Go 1.22 is dated as Modified Tue 06 Feb 2024 10:08:15 PM EST. The

[go-nuts] new range over int docs?

2024-02-06 Thread Jason E. Aten
The release notes https://go.dev/doc/go1.22 refer to the spec here https://go.dev/ref/spec#For_range but I do not see any details about the new for i := range 10 statement there. This is strange. Have the docs simply not been updated yet? But I do see this oddly out of place statement, where

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

[go-nuts] Go 1.22.0 is released

2024-02-06 Thread announce
Hello gophers, We have just released Go 1.22.0. To find out what has changed in Go 1.22, read the release notes: https://go.dev/doc/go1.22 You can download binary and source distributions from our download page: https://go.dev/dl/#go1.22.0 If you have Go installed already, an easy way to try

[go-nuts] Go 1.21.7 and Go 1.20.14 are released

2024-02-06 Thread announce
Hello gophers, We have just released Go versions 1.21.7 and 1.20.14, minor point releases. View the release notes for more information: https://go.dev/doc/devel/release#go1.21.7 You can download binary and source distributions from the Go website: https://go.dev/dl/ To compile from source

[go-nuts] Re: Error on installing package

2024-02-06 Thread Jason Phillips
Perhaps you wanted "go get 154.pages.dev/google@v1.4.0"? On Tuesday, February 6, 2024 at 11:36:11 AM UTC-5 Jason Phillips wrote: > There's no Go package at the root of that repo/module, and thus nothing to > install. "go install" only works on main packages. > > On Tuesday, February 6, 2024 at

[go-nuts] Re: Error on installing package

2024-02-06 Thread Jason Phillips
There's no Go package at the root of that repo/module, and thus nothing to install. "go install" only works on main packages. On Tuesday, February 6, 2024 at 8:34:07 AM UTC-5 Smit K wrote: > With this command: go install 154.pages.dev/goo...@v1.4.0 > > It

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread fgergo
(This time reply to list. Sorry Brian.) On Tue, Feb 6, 2024 at 3:03 PM 'Brian Candler' via golang-nuts wrote: > > > Thanks! In addition to that, It also helps with code with upper limit > > memory-requirement, which fmt.Sprintf() can't. > > If you're processing data from untrusted sources, then

[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

[go-nuts] Bound check optimization with "computed" index

2024-02-06 Thread Leonard Mittmann
I am trying to optimize the loop performance by reducing the number of bound checks. Inside the loop I compute a slice index and access two slice indexes like this: j := i / 2 s[j+1] = i s[j] = i // <- I want to get rid of this bound check I assumed that I can get rid of the second bound

Re: [go-nuts] Embedding an interface with a function type

2024-02-06 Thread Victor Manuel Giordano
Thanks El mar, 6 feb 2024 a las 12:05, Ian Lance Taylor () escribió: > On Tue, Feb 6, 2024 at 6:43 AM Victor Manuel “Vitu” Giordano > wrote: > > > > I'm wondering why the language allow me to write something like this: > > > > type IncFunc func(a int) int > > > > type Incrementor interface { >

Re: [go-nuts] Embedding an interface with a function type

2024-02-06 Thread Ian Lance Taylor
On Tue, Feb 6, 2024 at 6:43 AM Victor Manuel “Vitu” Giordano wrote: > > I'm wondering why the language allow me to write something like this: > > type IncFunc func(a int) int > > type Incrementor interface { > IncFunc // <-- THIS is allowed > IncQuantity() int > } > > (RTR example here) > > I

[go-nuts] Embedding an interface with a function type

2024-02-06 Thread Victor Manuel “Vitu” Giordano
Hi Goperhs! How you doing? Hope just fine! I'm wondering why the language allow me to write something like this: type IncFunc func(a int) int type Incrementor interface { IncFunc *// <-- THIS is allowed* IncQuantity() int } (RTR example here ) I don't get

[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

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread 'Brian Candler' via golang-nuts
> Thanks! In addition to that, It also helps with code with upper limit > memory-requirement, which fmt.Sprintf() can't. If you're processing data from untrusted sources, then you probably ought to validate it first. > How to use a limiting > io.Writer with fmt.Sprintf()? How would this limit

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

2024-02-06 Thread Pedro Luis Guzmán Hernández
multipart.Part, returned by multipart.Reader's NextPart method, have a Close() method. The only example here https://pkg.go.dev/mime/multipart#NewReader doesn't use the Close() method at all, so what's it purpose? Can we safely ignore it? The reason I'm asking is that, calling *defer

[go-nuts] Error on installing package

2024-02-06 Thread Smit K
With this command: go install 154.pages.dev/google@v1.4.0 It is not installing: [image: Screenshot 2024-02-06 180047.png] -- 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

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread fgergo
On Tue, Feb 6, 2024 at 12:18 PM 'Brian Candler' via golang-nuts wrote: > > The C functions are mainly there to prevent overrunning already-allocated > buffers, which isn't an issue with Go. Thanks! In addition to that, It also helps with code with upper limit memory-requirement, which

[go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread 'Brian Candler' via golang-nuts
The C functions are mainly there to prevent overrunning already-allocated buffers, which isn't an issue with Go. You could truncate the response: a := fmt.Sprintf("%s", "Blah blah blah")[0:10] You could use suitable precision specifiers: a := fmt.Sprintf("%.10s", "Blah blah blah")

[go-nuts] snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

2024-02-06 Thread fgergo
C *nprintf(3) implementations stop the conversion when n is reached. I couldn't find a similar functionality in the standard library, what did I miss? If there isn't any, any idea how to implement that without reimplementing all format helpers? thanks! -- You received this message because you