[go-nuts] The last line makes the variable y escape. But should it?

package main func newIntPtr(n int) *int { return &n } func main() { x := newIntPtr(3) y := newIntPtr(5) c := make(chan bool) go func() { *y++ close(c) }() <-c println(*x, *y) println(&x) //println(&y) // This line makes y escape. } -- You

Re: [go-nuts] Re: Is the escape analysis reports accurate?

021 at 4:25:18 AM UTC-4 tapi...@gmail.com wrote: > I will if I get enough time and become more familiar with the code. > Meanwhile, I think it is a not a bad idea to post my investigations here. > If some people with relevant experiences could make some explanations > without spending

Re: [go-nuts] The last line makes the variable y escape. But should it?

X) On Tuesday, June 1, 2021 at 10:26:04 AM UTC-4 Jan Mercl wrote: > On Tue, Jun 1, 2021 at 3:52 PM tapi...@gmail.com > wrote: > > By default, any local variable that has its address taken and that > address can outlive the function execution forces the variable to > esca

Re: [go-nuts] Re: Is the escape analysis reports accurate?

On Tuesday, June 1, 2021 at 10:48:22 AM UTC-4 Jan Mercl wrote: > On Tue, Jun 1, 2021 at 4:40 PM tapi...@gmail.com > wrote: > > > The following is a tip to get an array pointer but avoid the array > escaping. > > I don't think so. The pointer to the local arra

[go-nuts] Re: The last line makes the variable y escape. But should it?

, 2021 at 9:51:50 AM UTC-4 tapi...@gmail.com wrote: > > package main > > func newIntPtr(n int) *int { > return &n > } > > func main() { > x := newIntPtr(3) > y := newIntPtr(5) > c := make(chan bool) > go func() { > *y++ >

Re: [go-nuts] Re: Is this a bug ?

Another runnable example: package main const x = 8 var y = 8 var a byte = 1 << x / 2 var b byte = 1 << y / 2 func main() { println(a) // 128 println(b) // 0 } On Thursday, June 3, 2021 at 10:42:32 AM UTC-4 peterGo wrote: > Jan, > > The untyped constant 1 assumes the type of x, which is fl

[go-nuts] Surprising benchmark result

The code: https://play.golang.org/p/DxUj6kBqf8k The Filter4 function has one more assignment statement than Filter3. But the benchmark result shows Filter4 is faster than Filter3. The result: cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz BenchmarkFilter3-43575656 980.2 ns/op

[go-nuts] Re: Surprising benchmark result

On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote: > name time/op > Filter3-4 1.38µs ± 0% > Filter4-4 1.39µs ± 0% > > What is your CPU model? > > On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote: > >> >> The code: h

[go-nuts] It looks making a slice with size 32768+1 will allocate with one memory page as needed

package allocate import "testing" import "os" import "fmt" func init() { fmt.Println("OS page size:", os.Getpagesize()) } var r1 []byte func BenchmarkCount1(b *testing.B) { for i := 0; i < b.N; i++ { r1 = make([]byte, 32768+1) } } var r2 []byte func BenchmarkCount2(b *test

Re: [go-nuts] It looks making a slice with size 32768+1 will allocate with one memory page as needed

On Friday, June 11, 2021 at 2:00:03 PM UTC-4 Ian Lance Taylor wrote: > On Fri, Jun 11, 2021 at 9:38 AM tapi...@gmail.com > wrote: > > > > package allocate > > > > import "testing" > > import "os" > > import "fmt"

Re: [go-nuts] It looks making a slice with size 32768+1 will allocate with one memory page as needed

4 tapi...@gmail.com wrote: > On Friday, June 11, 2021 at 2:00:03 PM UTC-4 Ian Lance Taylor wrote: > >> On Fri, Jun 11, 2021 at 9:38 AM tapi...@gmail.com >> wrote: >> > >> > package allocate >> > >> > import "testing" >> > impo

Re: [go-nuts] It looks making a slice with size 32768+1 will allocate with one memory page as needed

On Saturday, June 12, 2021 at 12:04:21 PM UTC-4 Ian Lance Taylor wrote: > On Fri, Jun 11, 2021 at 11:21 PM tapi...@gmail.com > wrote: > > > > It looks the _PageSize constant used in allocating large memory block is > declared as 8192 in code, but os.Getpa

[go-nuts] string(aByteSlice) will duplicate undrelying bytes on stack if len(aByteSlice) <= 32

The benchmark code: https://play.golang.org/p/qp6wQgqcHKW The result: Benchmark_CompareWithSwitch0Bytes-4328873778 3.619 ns/op 0 B/op 0 allocs/op Benchmark_CompareWithSwitch32Bytes-4 175067815 6.251 ns/op 0 B/op 0 al

[go-nuts] Why does one string concatenation escape, but the other not?

package main import "testing" var s33 = []byte{32: 'b'} var a = string(s33) func main() { x := a + a // a + a does not escape println(x) } func Benchmark_e_33(b *testing.B) { var x string for i := 0; i < b.N; i++ { x = a + a // a + a escapes to heap } println(x

[go-nuts] Escape analysis result and benchmark result conflict

The code: package concat import ( "testing" ) var s33 = []byte{32: 'b'} var a = string(s33) func Benchmark_e_33(b *testing.B) { for i := 0; i < b.N; i++ { _ = a + a // a + a does not escape } } "go test -gcflags=-m" shows: a + a does not escape but "go test -bench=. -bench

[go-nuts] Re: Why does one string concatenation escape, but the other not?

Is this to avoid stack growing to fast if there are some stack allocations intervening with each other? On Wednesday, June 23, 2021 at 12:39:17 AM UTC-4 tapi...@gmail.com wrote: > > package main > > import "testing" > > var s33 = []byte{32: 'b'} > > v

[go-nuts] Re: Escape analysis result and benchmark result conflict

Is it possible that gc automatically replaces the "_" with a hidden declared package-level variable? On Wednesday, June 23, 2021 at 1:14:36 AM UTC-4 tapi...@gmail.com wrote: > The code: > > package concat > > import ( > "testing" > ) > >

[go-nuts] Re: Why does one string concatenation escape, but the other not?

e loop is set inside the loop does it > escape. > Yes, testing is not relevant here. It is the loop make effects here. > > On Wednesday, June 23, 2021 at 12:39:17 AM UTC-4 tapi...@gmail.com wrote: > >> >> package main >> >> import "testing"

[go-nuts] Re: Why does one string concatenation escape, but the other not?

cape > x = a + a // does not escape > for i := 0; i < 1; i++ { > > x = a + a // a + a escapes to heap > y := a + a // does not escape > println(y) > println(x) > } > } > > > Only when a variable outside the loo

[go-nuts] Re: Why does one string concatenation escape, but the other not?

Filled an issue: https://github.com/golang/go/issues/46908 On Thursday, June 24, 2021 at 10:50:31 PM UTC-4 tapi...@gmail.com wrote: > Now, I think the escape analysis message should be "a + a does not > escapes", > which accurate meaning is "the header part of a + a d

[go-nuts] gc uses different comparation operators to compare some thredshold values

The code: https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#L2012-L2025 xxx > ir.MaxStackVarSize xxx >= ir.MaxImplicitStackVarSize This leads to the elements of a slice with size as ir. MaxImplicitStackVarSize will be allocated

[go-nuts] Re: gc uses different comparation operators to compare some thredshold values

Sorry, a typo in title. It should be "comparison". On Saturday, June 26, 2021 at 5:50:55 AM UTC-4 tapi...@gmail.com wrote: > > The code: > https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/compile/internal/escape/escape.go#

Re: [go-nuts] Re: gc uses different comparation operators to compare some thredshold values

ess it > would be to file a bug. And if it's just curiosity, you can always try and > change it and see what breaks. Go has a lot of tests. > > On Sat, Jun 26, 2021 at 11:52 AM tapi...@gmail.com > wrote: > >> Sorry, a typo in title. It should be "comparison&qu

[go-nuts] Re: Named types vs not named types

A some weak reason not to support the change. Using unnamed parameter types could avoiding some explicit conversions. package main import "net/http" type MyHandlerFunc func(http.ResponseWriter, *http.Request) func f(http.HandlerFunc) {} func g(MyHandlerFunc) {} func h(func(http.ResponseWriter

[go-nuts] Stack growing is inefficient

It looks this line https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never gets executed. An example: package main const N = 512 * 1024 * 1024 // 500M var v byte = 123 func main() { var s = []byte{N: 0} for i := range s { s[i] = v } println(s[v]) } I added a p

[go-nuts] Re: Stack growing is inefficient

new goroutine still starts from 2048 bytes. On Wednesday, June 30, 2021 at 3:25:59 AM UTC-4 tapi...@gmail.com wrote: > > It looks this line > https://github.com/golang/go/blob/master/src/runtime/stack.go#L1078 never > gets executed. > > An example: > > package main &g

[go-nuts] Re: Stack growing is inefficient

Sorry, I post the wrong anchor. It is line 1068: https://github.com/golang/go/blob/d19a53338fa6272b4fe9c39d66812a79e1464cd2/src/runtime/stack.go#L1068 On Wednesday, June 30, 2021 at 5:08:30 AM UTC-4 Brian Candler wrote: > On Wednesday, 30 June 2021 at 08:25:59 UTC+1 tapi...@gmail.com wr

[go-nuts] Re: Stack growing is inefficient

> > > get run?" - is that right? Almost true. Whether or not it should run, growing the stack from 2048 to 512M in 18+ steps looks not right. > > On Wednesday, 30 June 2021 at 14:21:21 UTC+1 tapi...@gmail.com wrote: > >> Sorry, I post the wrong anchor. It

Re: [go-nuts] Re: Stack growing is inefficient

On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com wrote: > On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com > wrote: > >> >> >> On Wednesday, June 30, 2021 at 11:56:45 AM UTC-4 Brian Candler wrote: >> >>> So I think what you&#

Re: [go-nuts] Re: Stack growing is inefficient

e. > > V. > > On Thursday, 1 July 2021 at 03:03:37 UTC+2 tapi...@gmail.com wrote: > >> On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com >> wrote: >> >>> On Thu, Jul 1, 2021 at 2:34 AM tapi...@gmail.com >>> wrote: >>&

Re: [go-nuts] Re: Stack growing is inefficient

his change, the time needed to build the toolchain is reduced to 2m40.123s (from 3m3.897s). On Thursday, July 1, 2021 at 8:42:41 AM UTC-4 Jan Mercl wrote: > On Thu, Jul 1, 2021 at 2:34 PM tapi...@gmail.com > wrote: > > > It is not rare a function will use 10M+ stack. > > What&#x

Re: [go-nuts] Re: Stack growing is inefficient

f you are experiencing a real problem due to this, you might > want to open an issue. > > On Thu, Jul 1, 2021 at 3:04 AM tapi...@gmail.com > wrote: > >> >> >> On Wednesday, June 30, 2021 at 8:46:19 PM UTC-4 axel.wa...@googlemail.com >> wrote: >> >

Re: [go-nuts] Re: Stack growing is inefficient

; > . > > On Thu, Jul 1, 2021 at 3:23 PM tapi...@gmail.com > wrote: > >> Firstly, the current gc runtime implementation allows declare 10M arrays >> on stack. >> >> https://github.com/golang/go/blob/cca23a73733ff166722c69359f0bb45e12ccaa2b/src/cmd/co

Re: [go-nuts] Re: Stack growing is inefficient

Jul 1, 2021, at 9:28 AM, tapi...@gmail.com wrote: > >  > > I tried to find a way to initialize the size of the stack of a new created > goroutine in advance to avoid several stack copies. > Before this fix, the efficiencies of the two new goroutines are almost the > same. &

[go-nuts] Re: Surprising benchmark result

It is found that the test file is not written correctly. The filtered data should be reset in each loop. The corrected one: https://play.golang.org/p/yJMweZLIXAz <https://t.co/dZUGrAQ1cB?amp=1> ;D On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote: > > The

[go-nuts] How to pause/restart timer in a benchmark loop?

For example, I don't want the time consumed for "copy(data2, data)" being counted. How to achieve this? func BenchmarkFilter3(b *testing.B) { data := buildOrginalData() data2 := make([]int, len(data)) b.ResetTimer() for i := 0; i < b.N; i++ { copy(data2, data) _ =

[go-nuts] Re: How to pause/restart timer in a benchmark loop?

ednesday, July 7, 2021 at 11:28:13 AM UTC-4 tapi...@gmail.com wrote: > > For example, I don't want the time consumed for "copy(data2, data)" being > counted. > How to achieve this? > > func BenchmarkFilter3(b *testing.B) { > data := buildOrgin

[go-nuts] Re: How to pause/restart timer in a benchmark loop?

. Peter's solution exhausted my memory and hang my whole computer, and I have to restart it. > > On Wednesday, July 7, 2021 at 11:29:30 AM UTC-4 tapi...@gmail.com wrote: > >> This doesn't work: >> >> func BenchmarkFilter3(b *testing.B) { >> data := buildOr

[go-nuts] Re: How to pause/restart timer in a benchmark loop?

On Wednesday, July 7, 2021 at 8:01:54 PM UTC-4 tapi...@gmail.com wrote: > On Wednesday, July 7, 2021 at 12:32:38 PM UTC-4 jake...@gmail.com wrote: > >> It would be helpful to give more information as to why you say "This >> doesn't work"? >> But, I'

[go-nuts] Small number change will affect benchmark results

The benchmark code: https://play.golang.org/p/IqVnVa5x9qp When N == 16384, the benchmark result: Benchmark_Insert-4 134622 8032 ns/op 32768 B/op 1 allocs/op Benchmark_Insert2-4 132049 8201 ns/op 32768 B/op 1 allocs/op When N =

[go-nuts] Re: Small number change will affect benchmark results

piece of code would take to run, by generating a cycle-by-cycle > count. That's not possible any more :-) > > On Wednesday, 28 July 2021 at 15:43:38 UTC+1 tapi...@gmail.com wrote: > >> >> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp >> >> When N

Re: [go-nuts] Re: Small number change will affect benchmark results

On Wednesday, July 28, 2021 at 1:47:44 PM UTC-4 axel.wa...@googlemail.com wrote: > On Wed, Jul 28, 2021 at 7:30 PM tapi...@gmail.com > wrote: > >> I think this one is different from previous. I don't criticize Go, I just >> seek reasons. >> > >

Re: [go-nuts] Re: Small number change will affect benchmark results

chitectural > detail like cache-sizes mattering. Which of these it is, I don't know > either - but I'm not surprised enough to find out. > > On Wed, Jul 28, 2021 at 8:34 PM tapi...@gmail.com > wrote: > >> >> >> On Wednesday, July 28, 2021 at 1:47:44 PM U

Re: [go-nuts] Re: Small number change will affect benchmark results

On Wednesday, July 28, 2021 at 10:42:58 PM UTC-4 Kurtis Rader wrote: > On Wed, Jul 28, 2021 at 7:24 PM tapi...@gmail.com > wrote: > >> I will when I confirm that no one could give an answer without much >> effort. If you feel frustrated, you can ignored it. ;D >&

Re: [go-nuts] Re: Small number change will affect benchmark results

;oh, it's one of these again". >> >> Anyways. To repeat this one last time: I'd respectfully ask you to >> conduct a little bit more reasearch on your own, before sending these >> mails. Namely look at the generated code (the Compiler Explorer >&

[go-nuts] Re: Why isn't go more popular?

Personally, Go will become more popular if we could develop gfx/gui apps in Go with ease. On Thursday, August 5, 2021 at 10:20:49 PM UTC-4 santino.f...@gmail.com wrote: > When you see the ranking of the most liked programming languages, go is > near c++, a really "hated app". But since is effi

[go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

// main.go package main func main() { var s = []int{1, 2, 3} var pa = (*[2]int)(s[1:]) println(pa[1]) } $ go run main.go # command-line-arguments ./main.go:6:23: cannot convert s[1:] (type []int) to type *[2]int: conversion of slices to array pointers only supported as of -lang=

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

go1.17rc2? On Wednesday, August 11, 2021 at 4:46:06 PM UTC-4 Ian Lance Taylor wrote: > On Wed, Aug 11, 2021 at 7:45 AM tapi...@gmail.com > wrote: > > > > // main.go > > package main > > > > func main() { > > var s = []int{1, 2, 3} >

[go-nuts] Re: go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

BTW, go run -gcflags="-lang=go1.17" main.go doesn't work either. On Wednesday, August 11, 2021 at 10:45:05 AM UTC-4 tapi...@gmail.com wrote: > // main.go > package main > > func main() { > var s = []int{1, 2, 3} > var pa = (*[2]int)(s[1:]) > pri

Re: [go-nuts] Re: go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

; ./main.go $WORK/b001/_gomod_.go > ``` > > Notice "-lang" is passed two times, and the later "-lang=go1.16" wins. > > Cuong Manh Le > https://cuonglm.xyz > > > On Thu, Aug 12, 2021 at 7:56 AM tapi...@gmail.com > wrote: > >> BT

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor wrote: > On Wed, Aug 11, 2021 at 5:44 PM tapi...@gmail.com > wrote: > > > > But by not specifying the language version in go.mod, I think most > people would expect to use the latest features. &g

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

On Thursday, August 12, 2021 at 12:22:08 AM UTC-4 Ian Lance Taylor wrote: > On Wed, Aug 11, 2021 at 9:16 PM tapi...@gmail.com > wrote: > > > > On Thursday, August 12, 2021 at 12:12:13 AM UTC-4 Ian Lance Taylor > wrote: > >> > >> On Wed, Aug 11, 2021

Re: [go-nuts] go1.17rc2 fails to compile slice-to-array-pointer conversions if go.mod doesn't specify go directive

OK, I just found this: https://github.com/golang/go/issues/44976 It looks the language version is indeed defaulted to 1.16. On Thursday, August 12, 2021 at 12:36:37 AM UTC-4 tapi...@gmail.com wrote: > On Thursday, August 12, 2021 at 12:22:08 AM UTC-4 Ian Lance Taylor wrote: > >> On

Re: [go-nuts] Re: Why isn't go more popular?

fuel on > the fire" :-D > If we all keep being inspired with this wonderful language, then Go will > succeed, as we succeed :-) > HTH, Scottie > > tapi...@gmail.com schrieb am Mi., 11. Aug. 2021, > 07:45: > >> Personally, Go will become more popular if we could

[go-nuts] Re: Small number change will affect benchmark results

. On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote: > > The benchmark code: https://play.golang.org/p/IqVnVa5x9qp > > When N == 16384, the benchmark result: > > Benchmark_Insert-4 134622 8032 ns/op 32768 B/op >1 alloc

[go-nuts] Re: Small number change will affect benchmark results

More specifically, the last parameter (needzero) of mallocgc is not passed down to c.nextFree, which causes the memclrNoHeapPointers function is called twice in makeslicecopy if the slice size <= 32768. On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com wrote: > Spen

[go-nuts] Re: Small number change will affect benchmark results

The PR: https://github.com/golang/go/pull/47804 On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote: > More specifically, the last parameter (needzero) of mallocgc is not passed > down to c.nextFree, which causes the memclrNoHeapPointers function is > called

[go-nuts] Re: slices grow at 25% after 1024 but why 1024?

The problem of the current algorithm is it is not monotonically increasing: x1 := make([]int, 897) x2 := make([]int, 1024) y := make([]int, 100) println(cap(append(x1, y...))) // 2048 println(cap(append(x2, y...))) // 1280 And it is not symmetrical: x := make([]int, 98)

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote: > On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail.com > wrote: > >> The problem of the current algorithm is it is not monotonically >> increasing: >> > > Please explain why that is

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

lice grow algorithm should not depend on slice capacities. > > On Sat, 2021-09-04 at 20:57 -0700, tapi...@gmail.com wrote: > > > > > > On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader > > wrote: > > > On Sat, Sep 4, 2021 at 8:39 PM tapi

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

On Sunday, September 5, 2021 at 12:12:46 AM UTC-4 Kurtis Rader wrote: > On Sat, Sep 4, 2021 at 8:57 PM tapi...@gmail.com > wrote: > >> On Saturday, September 4, 2021 at 11:50:17 PM UTC-4 Kurtis Rader wrote: >> >>> On Sat, Sep 4, 2021 at 8:39 PM tapi...@gmail

[go-nuts] Re: Function to escape and unscape string

This is a known problem: https://github.com/golang/go/issues/8618 I looks the root cause is reflect.TypeOf and ValueOf make the values referenced by the arguments escape, though often this is over-cautious. On Sunday, August 29, 2021 at 3:02:42 PM UTC-4 nadashin wrote: > fmt.Printf has a format

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote: > On Sat, Sep 4, 2021 at 9:38 PM tapi...@gmail.com > wrote: > >> Why? That is an undocumented implementation detail. Furthermore, the >>> length of "x1" and "x2" at the time wh

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

On Sunday, September 5, 2021 at 2:26:23 AM UTC-4 axel.wa...@googlemail.com wrote: > On Sun, Sep 5, 2021 at 7:02 AM tapi...@gmail.com > wrote: > >> >> >> On Sunday, September 5, 2021 at 12:52:06 AM UTC-4 Kurtis Rader wrote: >> >>> On Sat, Sep 4, 202

[go-nuts] Named results allocated on stack instead of register?

Sometimes, a function with named results is slower. For example: https://play.golang.org/p/wvWkfSRqDLr The generated directives are almost the same for the two functions with a named and unnamed result, except one difference. For the function with the named result, the result represents as "".ret

[go-nuts] Re: Named results allocated on stack instead of register?

It looks this is related to code inlining. If we add //go:noinline directive for the two functions, then they have no performance difference. On Monday, September 20, 2021 at 12:39:51 PM UTC-4 tapi...@gmail.com wrote: > Sometimes, a function with named results is slower. > For example:

[go-nuts] It looks this is not a goal to make builtin generics be able to be defined/used by the custom generic rules?

Ian Lance Taylor mentioned that "That is true: that was not a goal": https://github.com/golang/go/discussions/47330#discussioncomment-1451011 Was? Does it mean it is now? -- You received this message because you are subscribed to the Google

[go-nuts] Re: Small number change will affect benchmark results

This is fixed in https://go-review.googlesource.com/c/go/+/359477 The benchmarks become much less weird. https://play.golang.org/p/leXp-8MB6gi On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote: > More specifically, the last parameter (needzero) of mallocgc is not pas

[go-nuts] What is the problem of the generic use?

package main import ( "fmt" ) type byteview interface{string | int} type ByteView[T byteview] struct {v [0]T} func (bv ByteView[T]) Write(v T) (int, error) { return 0, nil } type Writer[T byteview] interface { Write(bs T)(int, error) } type ioWriter = Writer[[]byte] // []byte doe

[go-nuts] Re: What is the problem of the generic use?

sorry, a mistake, "int" -> "[]byte". On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com wrote: > > package main > > import ( > "fmt" > ) > > type byteview interface{string | int} > > type ByteView[T byteview] s

[go-nuts] How the scopes of type parameters are defined?

I expect the following code compilers okay, but it doesn't. It looks All the three "I" in the Bar function declaration are viewed as the type parameter, whereas the second one is expected as the constraint I (at least by me). package main type I interface { M() } func Foo(i I) { i.M() } func

Re: [go-nuts] How the scopes of type parameters are defined?

arameters, if they conflict with the constraint you want to use) than > to take the hit of complex scoping rules with lots of exceptions. > > On Fri, Nov 12, 2021 at 9:48 AM tapi...@gmail.com > wrote: > >> I expect the following code compilers okay, but it doesn't.

[go-nuts] Is this a known problem?

func Bar[T []byte|string](s T) bool { for _, v := range s { // cannot range over s (variable of type T constrained by []byte|string) (T has no structural type) if v > 100 { return true } } return false } The message is quite confusing. -- You received th

Re: [go-nuts] Is this a known problem?

matters here? > > On Fri, Nov 12, 2021 at 3:18 PM tapi...@gmail.com > wrote: > >> >> func Bar[T []byte|string](s T) bool { >> for _, v := range s { // cannot range over s (variable of type T >> constrained by []byte|string) (T has no structural type) &g

Re: [go-nuts] Is this a known problem?

On Friday, November 12, 2021 at 11:40:53 PM UTC+8 axel.wa...@googlemail.com wrote: > On Fri, Nov 12, 2021 at 4:29 PM tapi...@gmail.com > wrote: > >> On Friday, November 12, 2021 at 11:10:17 PM UTC+8 >> axel.wa...@googlemail.com wrote: >> >>> `range s` w

[go-nuts] About struct fields in type parameters

The proposal design docs (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md) mentions: // structField is a type constraint whose type set consists of some // struct types that all have a field named x. type structField interface { struc

[go-nuts] Re: About struct fields in type parameters

pe T constrained by sliceOrMap } On Saturday, November 13, 2021 at 1:10:30 AM UTC+8 tapi...@gmail.com wrote: > The proposal design docs ( > https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md) > > mentions: > > // structField is

[go-nuts] Re: About struct fields in type parameters

The SliceConstraint example also doesn't work. Is the doc I mentioned outdated? On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmail.com wrote: > And this fails to compile, although the docs says it is valid: > > // sliceOrMap is a type constraint for a

Re: [go-nuts] How the scopes of type parameters are defined?

Fri, Nov 12, 2021 at 11:03 AM Axel Wagner > wrote: > >> >> >> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com >> wrote: >> >>> >>> >>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 >>> axel.wa...@googlemail.com wrote:

Re: [go-nuts] How the scopes of type parameters are defined?

> > On Fri, Nov 12, 2021 at 11:03 AM Axel Wagner > wrote: > >> >> >> On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com >> wrote: >> >>> >>> >>> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 >>> axel.wa...@

Re: [go-nuts] How the scopes of type parameters are defined?

On Friday, November 12, 2021 at 6:04:01 PM UTC+8 axel.wa...@googlemail.com wrote: > On Fri, Nov 12, 2021 at 10:54 AM tapi...@gmail.com > wrote: > >> >> >> On Friday, November 12, 2021 at 5:33:19 PM UTC+8 >> axel.wa...@googlemail.com wrote: >> >>

Re: [go-nuts] Re: What is the problem of the generic use?

i, Nov 12, 2021 at 6:18 AM tapi...@gmail.com > wrote: > >> sorry, a mistake, "int" -> "[]byte". >> >> On Friday, November 12, 2021 at 1:08:50 PM UTC+8 tapi...@gmail.com wrote: >> >>> >>> package main >>> >>>

Re: [go-nuts] Re: About struct fields in type parameters

what will land in go 1.18. > > On Fri, Nov 12, 2021 at 6:18 PM tapi...@gmail.com > wrote: > >> The SliceConstraint example also doesn't work. >> >> Is the doc I mentioned outdated? >> >> On Saturday, November 13, 2021 at 1:13:13 AM UTC+8 tapi...@gmai

[go-nuts] The runtime/slice_test.go shows most benchmarks become slower on tip (vs v1.17.3)

Slower about 20%. As least, on my machine, it looks so. As my machine is slow, I haven't use -count=10 and benchstat to make a report. -- 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

[go-nuts] Re: The runtime/slice_test.go shows most benchmarks become slower on tip (vs v1.17.3)

fill an issue here: https://github.com/golang/go/issues/49744 On Tuesday, November 23, 2021 at 12:15:52 AM UTC+8 tapi...@gmail.com wrote: > Slower about 20%. As least, on my machine, it looks so. > As my machine is slow, I haven't use -count=10 and benchstat to make a > report

[go-nuts] Re: compile time error vs runtime crash for same array

It is 1 << 50 is the limit on heap. The following code doesn't compile: package main func main() { var X [1 << 50]byte // type [1125899906842624]byte larger than address space _ = X } But with 1 << 50 - 1, it compiles: package main func main() { var X [1 << 50 - 1]byte // runtime:

[go-nuts] Re: compile time error vs runtime crash for same array

There is an issue for this: https://github.com/golang/go/issues/17378 On Sunday, November 14, 2021 at 1:46:29 AM UTC+8 arthurwil...@gmail.com wrote: > On a 64bit Mac, this code: > > package main > > var X [^uint(0)>>14]byte > func main() { > } > > produces a compile time error: > main.X: symbol

Re: [go-nuts] some incorrect code in blog.

Isn't the code should be: *func CopyFile() {* * ...* * if err != nil {* * return* * }* * defer func() { err = src.Close() }()* * ...* *}* On Thursday, November 25, 2021 at 12:18:20 PM UTC+8 Ian Lance Taylor wrote: > On Wed, Nov 24, 2021 at 6:14 PM Fannie Zhang wrote: > > > > The

[go-nuts] An mistake in tip spec?

https://tip.golang.org/ref/spec#Structure_of_interfaces interface{ int; any } // no specific types (intersection is empty) Why the constraint has no specific types. Doesn't it specify int? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

[go-nuts] Re: An mistake in tip spec?

Should it be interface{ int | any } // no specific types (intersection is empty) instead On Wednesday, January 5, 2022 at 11:20:16 PM UTC+8 tapi...@gmail.com wrote: > https://tip.golang.org/ref/spec#Structure_of_interfaces > >interface{ int; any } // no specific types (inters

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote: > 1. interface { a;b } is intersection. The "Intersection" between two sets > means things which exist in both sets simultaneously. > 2. interface { a|b } is union. "Union" means a set of things which which > exist in set A

[go-nuts] Re: An mistake in tip spec?

3. "interface { int; any }" is an *intersection* of *specific types* > > You are taking the intersection of the set of one type (int) with the > empty set, and therefore the result is the empty set. Exactly as the > comment says. > > On Thursday, 6 January 2022 at 11

[go-nuts] Re: An mistake in tip spec?

the set of one type (int) with the > empty set, and therefore the result is the empty set. Exactly as the > comment says. > > On Thursday, 6 January 2022 at 11:47:52 UTC tapi...@gmail.com wrote: > >> On Thursday, January 6, 2022 at 6:15:06 PM UTC+8 Brian Candler wrote: >>

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote: > So to be more specific, I think you're asking why this code works: > https://gotipplay.golang.org/p/kuYzzx4EJY1 > > Sorry, I made a mistake in interpreting the spec. It also says: > > "The type set of the empty interface is

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 9:40:49 PM UTC+8 Brian Candler wrote: > >> So to be more specific, I think you're asking why this code works: >> https://gotipplay.golang.org/p/kuYzzx4EJY1 >&g

[go-nuts] Re: An mistake in tip spec?

sorry again. It should be "the type set and specific types of interface{ int; any } are both {int}." On Thursday, January 6, 2022 at 9:45:35 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 9:44:05 PM UTC+8 tapi...@gmail.com wrote: > >> On Thursday, Janu

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote: > >> No, the mistake is in your reading of the spec. You are complaining >> about this line: >> >> interface{ i

[go-nuts] Re: An mistake in tip spec?

On Thursday, January 6, 2022 at 11:19:40 PM UTC+8 tapi...@gmail.com wrote: > On Thursday, January 6, 2022 at 9:40:52 PM UTC+8 tapi...@gmail.com wrote: > >> On Thursday, January 6, 2022 at 8:35:06 PM UTC+8 Brian Candler wrote: >> >>> No, the mistake is in your re

Re: [go-nuts] Re: An mistake in tip spec?

Thanks for the reply, gri. The latest generics design and implementation are much more beautiful than I expected, though I still think there are many restrictions. BTW, it looks the following line in spec becomes depreciated now, as now any type could be embedded in interfaces. In a slightly m

[go-nuts] The core type definition might be not right

The tip spec states that the core type of a constraint is born from the type set of the constraint. https://tip.golang.org/ref/spec#Core_types So the C constraint in the following program should have no core type, because its type set is blank. But the foo function compiles okay, which indicates

<    1   2   3   >