Re: [go-nuts] Equality of interface of an empty struct - why?

et your will at the time, you are now bringing it up to troll unrelated conversations. With no actually coherent position. And so your "one-sentence emoticon" message is neither charming, clever, witty nor funny. It's simply disrespectful.  On Thu, Feb 29, 2024 at 10:24 AM tapi..

Re: [go-nuts] Equality of interface of an empty struct - why?

On Thursday, February 29, 2024 at 3:14:40 PM UTC+8 Axel Wagner wrote: The loop var change *does* break compatibility. And it did so knowingly and - as clearly explained - was an exception. Stop arguing in bad faith. An exception. :D On Thu, Feb 29, 2024 at 7:03 AM tapi...@gmail.com

Re: [go-nuts] Equality of interface of an empty struct - why?

On Wednesday, February 28, 2024 at 3:19:37 PM UTC+8 Axel Wagner wrote: That would break backwards compatibility, though. And it would be a re-definition (i.e. existing code would compile, but behave differently at runtime) and is hence not allowed even under the Go 2 transition rules. With

Re: [go-nuts] Equality of interface of an empty struct - why?

On Tuesday, February 27, 2024 at 3:42:25 PM UTC+8 Jan Mercl wrote: On Tue, Feb 27, 2024 at 6:20 AM tapi...@gmail.com wrote: > From common sense, this is an obvious bug. But the spec is indeed not clear enough. > It doesn't state whether or not comparisons of pointers to two distinct

[go-nuts] Re: Failed to compile a generic code using embedded struct

use type Test[T, V interface{A; I}] struct{} instead now. There are still several restrictions in custom generics: https://go101.org/generics/888-the-status-quo-of-go-custom-generics.html On Monday, February 26, 2024 at 10:44:46 PM UTC+8 Albert Widiatmoko wrote: > Hi Go community, > > I

Re: [go-nuts] Equality of interface of an empty struct - why?

t;> it would be valid for `==` on pointers to zero-sized types to always evaluate to `true`, This would be more straightforward behavior. On Feb 26, 2024, at 9:24 AM, tapi...@gmail.com wrote: package main var a, b [0]int var p, q = , func main() { if (p == q) { p, q = , println(p

[go-nuts] Re: Equality of interface of an empty struct - why?

package main var a, b [0]int var p, q = , func main() { if (p == q) { p, q = , println(p == q) // false } } On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote: > I'm confused by this output. It appears that the interface of two > different pointers to an empty struct are

[go-nuts] Re: Equality of interface of an empty struct - why?

The behavior of Go 1.9 or 1.10 is even more weird. They make the following code print false. ;D package main type T struct {} func main() { var a, b = {}, {} println(a == b || a != b) } On Sunday, February 25, 2024 at 4:30:22 PM UTC+8 tapi...@gmail.com wrote: > Absolutely a

[go-nuts] Re: Equality of interface of an empty struct - why?

Absolutely a bug. On Thursday, February 22, 2024 at 6:55:49 PM UTC+8 Brien Colwell wrote: > I'm confused by this output. It appears that the interface of two > different pointers to an empty struct are equal. In all other cases, > interface equality seems to be the pointer equality. What's

[go-nuts] Re: It seems that go 1.22 has optimized the implementation of string to byte slicing and no longer requires memory allocation.

See https://github.com/golang/go/issues/2205 The tip compiler is able to detect some simple string->[]byte cases in which duplication is not needed. On Monday, November 27, 2023 at 8:12:54 PM UTC+8 fliter wrote: > It seems that go 1.22 has optimized the implementation of string to byte >

Re: [go-nuts] Generic type for struct method: constraint problem && cannot use (untyped string constant) as string value

The uint8 in cachedFn[uint8, V] is the type parameter name, it can be arbitrary valid identifier. It shadows the predeclared uint8 identifier. On Friday, November 10, 2023 at 12:25:05 PM UTC+8 ahuigo wrote: > Btw, please ignore the type logic in my code, I wrote this piece of code > just to

Re: [go-nuts] Can Generics match implementers of an interface?

My another surprise is that the below partial instantiation doesn't work. s = slices.Insert[[]Suiter](s, len(s), Clubs{}) // not work s = slices.Insert[[]Suiter, Suiter](s, len(s), Clubs{}) // works On Monday, October 23, 2023 at 11:01:47 AM UTC+8 tapi...@gmail.com wrote: > On Monday, Octo

Re: [go-nuts] Can Generics match implementers of an interface?

gt; figure it out. > > -Mike > On Sunday, October 22, 2023 at 11:01:47 PM UTC-4 tapi...@gmail.com wrote: > >> On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote: >> >> Sorry, I didn't look your full code. >> I think the full code should w

Re: [go-nuts] Can Generics match implementers of an interface?

On Monday, October 23, 2023 at 10:38:59 AM UTC+8 tapi...@gmail.com wrote: Sorry, I didn't look your full code. I think the full code should work with Go toolchain 1.21.n. Aha, it actually doesn't. I'm surprised. On Sunday, October 22, 2023 at 4:40:55 PM UTC+8 Mike Schinkel wrote: How so

Re: [go-nuts] Can Generics match implementers of an interface?

her negative? > > -Mike > > On Saturday, October 21, 2023 at 11:57:52 PM UTC-4 tapi...@gmail.com > wrote: > > > It is hard to call such type inference better. That is too aggressive. > > -- You received this message because you are subscribed to the Google Groups "gol

Re: [go-nuts] Can Generics match implementers of an interface?

On Sunday, October 22, 2023 at 4:09:51 AM UTC+8 Mike Schinkel wrote: @Axel Wagner — Thank you for adding clarity to this. Yes, it would be nice if we could get this to be handled with better type inference. It is hard to call such type inference better. That is too aggressive. But

Re: [go-nuts] Possible Go Compiler or Runtime bug?

On Friday, July 28, 2023 at 6:44:21 AM UTC+8 wagner riffel wrote: On 27/07/2023 03:48, Kyle Harrity wrote: > Maybe this is a known issue and or expected behavior so I thought I'd > ask here before raising an issue on github. > I think I know what's going on, the compiler inlined getStrBytes

[go-nuts] Re: Short Variable Declarations Are Oversold

Type inference is not the main purpose (or even the purpose) of short declarations. I do agree that the negative impact of short declarations is larger than its positive impact, for reasons different from the one you described. Some reasons: * short declarations causes confusions (esp, for new

[go-nuts] Re: Redfining loop variable semantics - what's the plan?

Not to mention that the change for "for;;" is so counter-intuitive and violates the try-to-be-explicit principle in Go. On Wednesday, April 12, 2023 at 9:08:24 AM UTC+8 tapi...@gmail.com wrote: > The plan for “for;;” is much more risky than “for-each”, because “for;;” > has mor

[go-nuts] Re: Redfining loop variable semantics - what's the plan?

The plan for “for;;” is much more risky than “for-each”, because “for;;” has more variation uses in reality. I have no doubt that many non-bug compatibility-broken or performance-degradation cases will be found in the GOEXPERIMENT phase. On Saturday, March 25, 2023 at 2:44:59 PM UTC+8 Amnon

Re: [go-nuts] Create a 1GB ballast but it takes up RSS and pages are Dirty?

I ever also found this problem: global ballast doesn't work. So I always use local ballast instead now. On Sunday, November 6, 2022 at 8:37:55 PM UTC+8 hit.zh...@gmail.com wrote: > Before, I think the memory is allocated by mmap anon, which Linux OS > guarantees reading will return zero value

Re: [go-nuts] godoc and generic code

You may also try Golds: https://github.com/go101/golds. Still not perfect in handling custom generic things, but it is generally usable. On Friday, November 4, 2022 at 1:26:26 AM UTC+8 Hotei wrote: > Thanks for the very helpful replies. < go doc -all pkg > should meets my > needs for printed

Re: [go-nuts] Re: What's the maximum array length?

ay that your reply is invalid. I'm just curious how you view your reply as >> being more clear than mine. :-) >> >> >>> On Fri, Oct 28, 2022 at 8:57 PM tapi...@gmail.com >>> wrote: >>> >>>> The max array length is math.MaxInt. "[math.M

[go-nuts] Re: What's the maximum array length?

The max array length is math.MaxInt. "[math.MaxInt]struct{}" is valid, though the practical size of non-zero-size array is hard limited in some way. On Friday, October 28, 2022 at 9:43:16 AM UTC+8 eric...@arm.com wrote: > The spec says that " The length is part of the array's type; it must >

[go-nuts] Re: What is the relationship between go community and goproxy.io

On Monday, October 10, 2022 at 3:11:06 PM UTC+8 Brian Candler wrote: > > By the go module cache system design, if you trust the server set in > your GOSUMDB env var, > > which is defaulted to sum.golang.org, then it is not a matter whatever > proxy server your are using. > > From the point of

[go-nuts] Re: What is the relationship between go community and goproxy.io

On Sunday, October 9, 2022 at 11:50:49 PM UTC+8 ljh wrote: > Hi, community, > > I Just saw this site: yunzhanghu.com , is listed as Special Sponsor on > goproxy.io homepage. > > I'm just curious, is goproxy.io endorsed by The Go Team and is goproxy.io > trustworthy? > By the go module cache

[go-nuts] Re: private go documentation server similar to https://pkg.go.dev

I don't know if it satisfies your need, but you can try Golds: https://go101.org/apps-and-libs/golds.html On Sunday, September 11, 2022 at 5:28:35 AM UTC+8 brainman wrote: > Hello Everyone, > > I would like to run go documentation server that have access to my private > code. > > Is it

[go-nuts] Re: Go 1.19 average goroutine stack

On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote: > On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote: > >> On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com >> wrote: >> >>> I'm a bit wonde

[go-nuts] Re: Go 1.19 average goroutine stack

s 0%: 0.098+2.6+0.011 ms clock, 0.39+0/2.5/7.5+0.044 ms cpu, 0->0->0 MB, 118 MB goal, 128 MB stacks, 8 MB globals, 4 P (forced) 2022/08/20 22:52:02 16777216 3 On Saturday, August 20, 2022 at 10:58:10 PM UTC+8 tapi...@gmail.com wrote: > On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k

[go-nuts] Re: Go 1.19 average goroutine stack

On Friday, August 19, 2022 at 12:14:55 AM UTC+8 k...@google.com wrote: > On Wednesday, August 17, 2022 at 8:18:35 PM UTC-7 tapi...@gmail.com wrote: > >> I'm a bit wondering about how the following case will be affected by the >> change: >> 1. Initially, there is one gor

[go-nuts] Re: Go 1.19 average goroutine stack

I'm a bit wondering about how the following case will be affected by the change: 1. Initially, there is one goroutine, which stack size is large at the time of a GC process. 2. After the GC process, a large quantity of goroutines start. They all need small stacks. But now the runtime will

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

I tend to think it should print 1, as well this one: https://go.dev/play/p/bax7CoaSV1d On Monday, August 15, 2022 at 3:34:35 PM UTC+8 tapi...@gmail.com wrote: > It would be good if the Memory Model article shows some atomic examples. > > On Monday, August 15, 2022 at 3:06:58 PM

[go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

By the latest version of Go Memory Model article: https://go.dev/ref/mem, will the following program always print 1? https://go.dev/play/p/RICYGip5y8M -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop

Re: [go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

I can recommend but not force them to use a recent version. And this is not a 1.15/1.16 specific problem. > > On Tuesday, 10 May 2022 at 01:24:12 UTC+1 tapi...@gmail.com wrote: > >> On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote: >> >>> On Mon, May 9, 2

Re: [go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote: > On Mon, May 9, 2022 at 10:18 AM tapi...@gmail.com > wrote: > > > > I have a project using go1.16 embedding feature. > > The project supports Go toolchain 1.15, by using "//go:build !go1.16&q

[go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

I have a project using go1.16 embedding feature. The project supports Go toolchain 1.15, by using "//go:build !go1.16" directive. Now I have upgraded the toolchain to v1.18.1, And I want to debug the non-embedding flow of the project. Changing the go version in go.mod doesn't help. Do I have

Re: [go-nuts] Refactor to use generics to have a single Make

On Wednesday, May 4, 2022 at 7:01:48 AM UTC+8 se...@liao.dev wrote: > right now it only works if the structs are actually identical: > https://go.dev/play/p/tMG3SYG5fLN > > - sean > > Though accessing fields is still not allowed. > > On Tue, May 3, 2022 at 8:06 PM sbezverk wrote: > >>

Re: [go-nuts] Are the two constraints equivalent to each other?

Ah, I forgot that point. Thanks for the explanation! On Saturday, April 2, 2022 at 10:00:27 PM UTC+8 axel.wa...@googlemail.com wrote: > Ptr[int] is a defined type, `*int` is not. So the two types are not the > same and this is working as intended. > > On Sat, Apr 2, 2022 at

[go-nuts] Are the two constraints equivalent to each other?

package main type Ptr[E any] *E type MyConstraint interface { Ptr[int] } type YourConstraint interface { *int } func foo[T MyConstraint](x T) { } func bar[T YourConstraint](x T) { } func main() { var x = new(int) foo(x) // *int does not implement MyConstraint bar(x) }

Re: [go-nuts] Unexpected order of global variable declaration during package initialization

Aha, sorry, the file order really matters here. But for this specified case, it should not. That's not right. I remembered in an issue thread, it is mentioned that the order should be 1. D is not ready (because it depends on A) 2. A is ready, so it is initialized: it gets value 3. 4. B is

Re: [go-nuts] Is it safe to say two unname interface types are identical if their type sets are identicial?

Then I think interface{int; m()} and interface{bool;; m()} should be identical. Because their type sets are both empty.. On Thursday, March 24, 2022 at 7:38:10 PM UTC+8 Jan Mercl wrote: > On Thu, Mar 24, 2022 at 11:58 AM tapi...@gmail.com > wrote: > > https://go.dev/ref/spec#T

Re: [go-nuts] Unexpected order of global variable declaration during package initialization

BTW, the rewritten version outputs Init A Init B Init C 1 4 3 On my machine (go1.18 linux/amd64). On Thursday, March 24, 2022 at 7:30:37 PM UTC+8 tapi...@gmail.com wrote: > > 2. A < D < B < C - happens when f2.go is passed first to the compiler. > In this case, the *expe

Re: [go-nuts] Unexpected order of global variable declaration during package initialization

> 2. A < D < B < C - happens when f2.go is passed first to the compiler. In this case, the *expected output *would be "1 2 1". However, the *actual output* is "1 2 3". This is not true by my understanding of the spec. https://go.dev/ref/spec#Package_initialization If f2.go is passed first,

[go-nuts] Is it safe to say two unname interface types are identical if their type sets are identicial?

. -- 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 email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit

Re: [go-nuts] Re: Is there a way to eliminate the code repetition in the code?

Is it hard to add two predeclared constraints, convertibleFrom and convertibleTo, just like comparable? On Tuesday, March 22, 2022 at 11:07:41 PM UTC+8 Ian Lance Taylor wrote: > On Tue, Mar 22, 2022 at 6:01 AM tapi...@gmail.com > wrote: > > > > > > > > On Monday

[go-nuts] Re: Is there a way to eliminate the code repetition in the code?

] = vs[i] } return r } > > > On Sunday, March 20, 2022 at 11:36:27 PM UTC+7 tapi...@gmail.com wrote: > >> >> >> package main >> >> type A interface { >> Ma() >> } >> >> type B interface { >>

[go-nuts] Re: type parameters and named type

> *type parameters *itself is not a type, but a list of type parameters. true. The spec means a single type parameter is a named type. On Monday, March 21, 2022 at 12:12:26 AM UTC+8 xiej...@gmail.com wrote: > Hi there. > > I am reading go spec. When hit the "Types" section, > >

[go-nuts] Is there a way to eliminate the code repetition in the code?

package main type A interface { Ma() } type B interface { Mb() } type Ta struct { A } type Tb struct { B } func ConvertSliceToA[From A](vs []From) []A { var r = make([]A, len(vs)) for i := range vs { r[i] = vs[i] } return r }

[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

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

[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 you

[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?

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: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?

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

[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?

nterface { 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:47:52 UTC

[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

[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 (int

[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

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: > > > >

[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

[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 //

[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] 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

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

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...@gmail.com >

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?

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 wro

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?

v 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 >>> >>> imp

[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 slice

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

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 a typ

[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 {

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

, 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` wor

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

[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

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

ers, 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. >> It

[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

[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] 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

[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] 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

[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] 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

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

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

[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: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

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

ow 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 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 tha

[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)

[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 > cal

[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

ation. 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

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

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 deve

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] 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

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

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

o $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: > >> BTW, >&g

[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:]) > println(

  1   2   3   >