[go-nuts] Why is foo in my go.sum file?

The go.sum file in the golang.org/x/image repo has a line that is not another golang.org.x/* module: github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= https://github.com/golang/image/blob/2b687b56714d59d061135c735913a64fe2b70778/go.sum#L1 That line was added

Re: [go-nuts] weird "index out of range" in strconv.formatBits

Thanks. >> Have you eliminated the possibility of races? We're trying to extract a smaller case for reproducing (perhaps impractical, as the frequency of the panic is way low) then apply the race detector, enabling race check online is not an option now, sadly. >> Have you built with CGO_ENABL

Re: [go-nuts] Crash using gccheckmark=1, possible GC bug?

On Thu, Aug 17, 2023 at 5:41 PM Tibor Halter wrote: > > I get this crash when using the GODEBUG option gccheckmark=1: > > runtime: marking free object 0xc0016c5668 found at *(0xc0046ca8e0+0x8) > base=0xc0046ca8e0 s.base()=0xc0046ca000 s.limit=0xc0046cc000 s.spanclass=8 > s.elemsize=32 s.state=mSp

[go-nuts] Crash using gccheckmark=1, possible GC bug?

Hi! I get this crash when using the GODEBUG option gccheckmark=1: runtime: marking free object 0xc0016c5668 found at *(0xc0046ca8e0+0x8) base=0xc0046ca8e0 s.base()=0xc0046ca000 s.limit=0xc0046cc000 s.spanclass=8 s.elemsize=32 s.state=mSpanInUse *(base+0) = 0x15e11f0 *(base+8) = 0xc0016c5668 <=

Re: [go-nuts] Why is reflect.Type defined as an interface, but reflect.Value is defined as a struct?

On Thu, Aug 17, 2023 at 10:02 AM Hu Jian wrote: > > I'm curious why reflect.Type is defined as an interface, but reflect.Value is > defined as a struct? I don't see any other implementation of the reflect.Type > interface. reflect.Value is an ordinary struct. The reflect.Type interface is real

[go-nuts] Why is reflect.Type defined as an interface, but reflect.Value is defined as a struct?

hi all, I'm curious why reflect.Type is defined as an interface, but reflect.Value is defined as a struct? I don't see any other implementation of the reflect.Type interface. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from t

[go-nuts] Re: how to constrain a type

Then make a dummy interface, with a method with a unique name that you never call. On Thursday, 17 August 2023 at 16:48:28 UTC+1 Mark wrote: > Hi Brian, > Sorry for not being clearer. Ideally I don't want an interface: each Shape > is essentially a store of different kinds of values so at some

[go-nuts] Re: how to constrain a type

I'm not sure without knowing *how* you want to use []*Shape{}. Perhaps you want Shape to be an interface? type Shape interface { DrawMe() } type BoxShape struct ... func (*BoxShape) DrawMe() { } type LineShape struct ... func (*LineShape) DrawMe() { } shapes := []Shape{} (Note that inter

Re: [go-nuts] keyword= support for function calls

Even if we assume that the addition of keyword arguments would be a positive for the Go language and ecosystem, it wouldn't be a backward compatible change to add a keyword argument unless we make additional changes to the language to support implicit conversions between function-with-keyword t

Re: [go-nuts] keyword= support for function calls

On Thu, 2023-08-17 at 11:34 +0200, Peter Herth wrote: > I think the omission of keyword parameters in Go is a weakness. In > many cases, keyword parameters are a simple way of creating APIs, > which depend on a lot of possible parameters, of which most are not > necessarily specified. Their omissio

Re: [go-nuts] keyword= support for function calls

I think the omission of keyword parameters in Go is a weakness. In many cases, keyword parameters are a simple way of creating APIs, which depend on a lot of possible parameters, of which most are not necessarily specified. Their omission is especially ironic, as there is a strong push to initializ

[go-nuts] Re: Test coverage: joint unit test and integration test coverage

I tried to use the `-test.gocoverdir` (*) and while the test(s) being executed use the given directory, unfortunately it still sets `GOCOVERDIR` to some newly created temporary directory. Since my integration tests are executed from a *_test.go

Re: [go-nuts] keyword= support for function calls

The reason `os.Open` has not changed is because it doesn't have to change. None of the features you mention really make sense for what it does. At least that would be my interpretation. If you want to support your interpretation, I would suggest digging up proposals to add those features which got