Re: [go-nuts] Re: Cannot instantiate T(ype) passed as pointer T?

I'm not *entirely* sure what you are asking, but does this help, perchance? https://gotipplay.golang.org/p/DmxDIdHrV8o On Thu, Jul 21, 2022 at 8:10 AM Slawomir Pryczek wrote: > Actually this is better code for the question > https://gotipplay.golang.org/p/GQlB2tyyj53 > > czwartek, 21 lipca 2022

[go-nuts] Re: Cannot instantiate T(ype) passed as pointer T?

Actually this is better code for the question https://gotipplay.golang.org/p/GQlB2tyyj53 czwartek, 21 lipca 2022 o 08:08:51 UTC+2 Slawomir Pryczek napisał(a): > https://gotipplay.golang.org/p/ojY3RRJRJgy > > func GenericData[T DATA, T1 any]() { > } > > When DATA is interface of pointer type, so m

[go-nuts] Cannot instantiate T(ype) passed as pointer T?

https://gotipplay.golang.org/p/ojY3RRJRJgy func GenericData[T DATA, T1 any]() { } When DATA is interface of pointer type, so methods can modify the underlying structure... // T1 <- any type, so can instantiate but can't increment as there's no interface var tt T1 fmt.Println(tt) var d T

Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?

On Wed, 2022-07-20 at 22:51 +0200, 'Axel Wagner' via golang-nuts wrote: > The reason reflect uses panic, is for convenience. It would be > inconvenient having to check an error at every reflect call. The other reason is that a panic in reflect is as close as you can get in runtime to a compile err

Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?

Which is also the distinction between checked and unchecked exceptions. Checked exceptions force the caller to deal with potential errors and are harder to ignore than error codes. > On Jul 20, 2022, at 3:52 PM, 'Axel Wagner' via golang-nuts > wrote: > >  > The reason reflect uses panic, is

Re: [go-nuts] doc comment links to non-imported packages due to import cycles

On Wed, Jul 20, 2022 at 11:07 AM TheDiveO wrote: > > https://go.dev/doc/comment says: > > When referring to other packages, “pkg” can be either a full import path or > the assumed package name of an existing import. The assumed package name is > either the identifier in a renamed import or else

Re: [go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?

The reason reflect uses panic, is for convenience. It would be inconvenient having to check an error at every reflect call. Personally, I strongly disagree with the advice you quote by Dave. Mainly, because it doesn't actually tell you what "truly exceptional" means. To me, the rule of thumb is:

[go-nuts] Methods of reflect pkg use mostly panic instead of return error. Why so?

Hi, for sure i know final Go proverb -- "Don`t panic". Also Dave.Cheney "The simple rule of thumb is panic should only be used in truely exceptional cases, which, as their name suggests are rare." Also I know there are exist circumstances where explicit panic() call looks reasonable. I`d like to

[go-nuts] doc comment links to non-imported packages due to import cycles

https://go.dev/doc/comment says: *When referring to other packages, “pkg” can be either a full import path or the assumed package name of an existing import. The assumed package name is either the identifier in a renamed import or else the name assumed by goimports

[go-nuts] Re: Go build but module-aware mode

I can't. My problem is that I can't access github.com// . Either it does not exist. Or user has made the repo private on Github. [image: Screenshot 2022-07-20 at 15.07.31.png] On Wednesday, 20 July 2022 at 15:04:48 UTC+1 rich...@gmail.com wrote:

[go-nuts] Go build but module-aware mode

Hi, is there any way to build source from given path@version just like `go run` and `go mod`? What i got: > go build -o main_x github.com//@latest package github.com//@latest: can only use path@version syntax with 'go get' and 'go install' in module-aware mode (and maybe putting

[go-nuts] Re: Best way of implementing generic binary search?

Thanks everyone, was able to make this working by passing a function with same type. wtorek, 19 lipca 2022 o 15:17:39 UTC+2 Brian Candler napisał(a): > You don't need a compare method on your type. You can just pass a func(T, > T) bool to your search function. > > In fact, the standard library

Re: [go-nuts] goroutine private / local var/const

On Wed, Jul 20, 2022 at 01:00:59PM +0300, Konstantin Khomoutov wrote: > > for i=0;i<10;i++ { go func () { /* const c=i OR var v=i */ > > fmt.Println("f:beg i=",i) // here c or v instead > > // action > > fmt.Println("f:end i=",i) // here c or v instead > > }} [...] > - Make your anonymous

Re: [go-nuts] goroutine private / local var/const

On Tue, Jul 19, 2022 at 08:28:02AM -0700, 'andreas graeper' via golang-nuts wrote: > for i=0;i<10;i++ { go func () { /* const c=i OR var v=i */ > fmt.Println("f:beg i=",i) // here c or v instead > // action > fmt.Println("f:end i=",i) // here c or v instead > }} > when this routines get inte